You are not logged in. Please login or register.
PunBB Forums → PunBB 1.2 discussion → why not session?
As I was reviewing punbb code, I see that it will fetch the user info from the users table every time he see a page.
i wonder it would not be faster to use SESSION variables or maybe a heap table to store required info of online users to get rid of accessing big users table each time?
please help me as soon as possible so i can advance my work.
No, the data need to be verified anyway, so store all the user data in a session wouldn't be very good.
you mean that the SESSION data must be verified with users table each time?
are SESSION variables as unsafe as this?
another thing is why not storing online user data in a heap instead of anything else!
another thing is why not storing online user data in a heap instead of anything else!
It is 
http://dev.mysql.com/doc/refman/5.0/en/ … ngine.html
About sessions, PunBB uses cookies and I think it's mainly because of this reason (from php.net):
sessions and security
The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.
There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.
And you can change your cookie however you'd like which result in that the user data have to be fetched from the database to be considered valid.
Jansson: I don't think that's why, becaused a leaked PunBB cookie is potentially much worse than a session ID (a session ID needs to be kept active: if the user doesn't change their password the cookie is always valid).
I think one reason would be that session data stored normally as files in a shared server environment would be vulnerable to anyone else on the server reading the data
Also, what's the benefits to a session? You don't want to cache the data in a session because it could have been updated. There's no way you can really store it.
Yes Smartys, that's basically what it's saying. But not only other users on the server, people in between and also social engineering is a serious threat to sessions
Jansson: I don't think that's why, becaused a leaked PunBB cookie is potentially much worse than a session ID (a session ID needs to be kept active: if the user doesn't change their password the cookie is always valid).
Under what circumstances would a cookie be leaked? The only way to do so would be physically gaining access to the user's box, and in which case, losing your password is the least of your concerns.
i think if the sid is omited from the urls (my condition), the SESSION would be safe enough - so why using cookie and query instead of SESSION?
As i know it's not possiblie to use transparent sid in all servers and this is the reason.
Another thing I want to know is this, how much oveload does this query impose on the server and wheter if it cost to change the method?
Actually pun_bb uses bad data to create the cookie (user_id, password). i think it's much better to have a cookie_rand(int) filed in the users table and each time user login we make a random number and update the cookie_rand with this then store this cookie (user_id, cookie). this method have two benefit:
1- if the cookie is captured it will be valid for a limited time, not till the password is changed
2- if the user login on another computer the return to his own, the cookie on the other machine will be valid no longer
the problem of implementing this is the punbb login method which will query the database each time, so we must update the cookie each time.
wondering what to do?
2- if the user login on another computer the return to his own, the cookie on the other machine will be valid no longer
I don't think this is the wanted behaviour. I would personally not like it since I'm on several computers.
Also, what's the benefits to a session? You don't want to cache the data in a session because it could have been updated. There's no way you can really store it.
what do you mean?
Alli wrote:2- if the user login on another computer the return to his own, the cookie on the other machine will be valid no longer
I don't think this is the wanted behaviour. I would personally not like it since I'm on several computers.
Actually this is better. because sometimes you may login on someone else computer and forget to logout. so he would get access to your account.
Jansson wrote:Alli wrote:2- if the user login on another computer the return to his own, the cookie on the other machine will be valid no longer
I don't think this is the wanted behaviour. I would personally not like it since I'm on several computers.
Actually this is better. because sometimes you may login on someone else computer and forget to logout. so he would get access to your account.
Then I wouldn't blame PunBB 
IMHO, the best solution for this is (I think I've proposed this before) to have a checkbox in the login form whether or not to save the cookie. This way, I could always be logged in on my own computer, and I can do temporary logins from others (without having to worry about logout).
Smartys wrote:Also, what's the benefits to a session? You don't want to cache the data in a session because it could have been updated. There's no way you can really store it.
what do you mean?
I mean what I said 
Sessions are useful if you're using them to store data about the user. PunBB can't store much data in a session because it would make it hard to update when it gets updated. So, why use a session when the cookie serves just as well?
I don't have any problem with the cookie, but with query on users table for each page aaa user see. i wonder how much overload does it impose on the server. you may answer no overload because of data caching of DBMS! i don't know!
Have you tried PUN_SHOW_QUERIES? Then you can see for yourself and guesstimate the server load for that one query. I think you would see that the few milliseconds that query takes to perform is worth the security issues using sessions would introduce.
what about a site with more than 200 users online in a time? i want to know how other forum like vbulltin handle this issue? I must see.
I don't know how vbulletin do this in detail, though I'm quite sure they use cookies. But all I know for certain is that PunBB can handle 200 users simultaneously.
I don't know how vbulletin do this in detail, though I'm quite sure they use cookies.
I end up with 7 cookies after visiting a vBulletin forum where I'm a member. 
the cookie itslef is not important, but the way they handle it on the server is important!!!!
Probably the same way as PunBB does since it has to be verified.
I for one won't welcome any change that would see punBB URL's looking like:
http://www.phpbb.com/phpBB/viewforum.php?f=1&sid=b8159808354ts356f50a7f14bd782856345eProbably not good for SEO either.
The way punBB handles things at the moment seems fine to me...
using of session doesn't actully mean http://www.phpbb.com/phpBB/viewforum.ph … 782856345e
you can turn it off easily
Does ip-address also checked along with the cookie ?
what about a site with more than 200 users online in a time? i want to know how other forum like vbulltin handle this issue? I must see.
I think this would proof enough
Currently:
Registered users online: 48
Guests online: 268
PunBB Forums → PunBB 1.2 discussion → why not session?
Powered by PunBB, supported by Informer Technologies, Inc.