Re[2]: [PEAR] session cross between users? SOLVED!

Hi, Monday, November 22, 2004, 11:52:11 AM, vas escriure: VD> Hello, VD> I see your comment about Smarty. I also use smarty to cache VD> some generated pages, where the only difference between users is VD> their session. The URL is the same but users see different content VD> depending on some flags in their PHP SEssion. Do you believe VD> Smarty could give the same page to various users? I believe it because I have seen it. If caching is set to true, this problem appears. The thing I don't know is if this problem depens on php configuration. If you think that you can have this problem make a test. With two users in differents machines try to click at the same time parox the same page with different parameter, for example: product.php?id=45 and product.php?id=22 The page that is faster will be cached and the second user receives the page and the parameter of the first user. If you try this, explain your experience here please. VD> Vincent VD> -----Original Message----- VD> From: Leo Márquez [mailto:leo@calidae.net] VD> Sent: lundi 22 novembre 2004 10:57 VD> To: pear-general@lists.php.net VD> Subject: [PEAR] session cross between users? SOLVED! VD> Hi again!, VD> The problem is solved. It was a problem with Smarty and caching. VD> Probably a Smarty bug? VD> We have a page as product.php which have to show a product. The urls VD> from differents users can be: VD> product.php?id=334 VD> product.php?id=256 VD> Smarty catch the page from the first user (the faster) and serve the VD> same page to the second. Smarty has not consideration to the VD> querystring parameter? VD> This list is not the place to ask it but I was needed to explain the VD> end of this thread that has taken part a few persons. VD> We have deactivated the caching os Smarty and the application works VD> fine. VD> See you. VD> Friday, November 19, 2004, 6:41:11 PM, vas escriure: JP>> On Fri, 19 Nov 2004 09:27:55 +0100, Leo Márquez <leo@calidae.net> wrote: >>> Hi!, >>> >>> I'm using file based php sessions under php5. >>> The thing surprised my is that we are talking about this problem >>> 'quitely' and I think is a very serious problem that php would have >>> resolved. Perhaps I don't understand the base of problem and my >>> session handler code is bad but I think is a php session system >>> responsability. >>> >>> Sorry about my poor english. >>> JP>> Yes, this would probably have been dealt with before now, but perhaps JP>> you've got the right (wrong) conditions for a new bug. Perhaps.... JP>> Are you saying that you have your own session handler? Could you show us that? >>> Thanks. >>> >>> Thursday, November 18, 2004, 11:30:09 PM, vas escriure: >>> >>> JP> On Thu, 18 Nov 2004 23:09:25 +0100 (CET), leo@calidae.net >>> JP> <leo@calidae.net> wrote: >>> >> Well, I'm using Auth to validate users in my application. >>> >> The solution that says Justin means that every time I have a cross session >>> >> now forces a logout in the application? >>> >>> JP> It should be possible to not force a logout, but I couldn't find it >>> JP> quickly. If you do some more research on creating a new session you >>> JP> should be able to do it. You could also use PEAR's HTTP_Session. >>> >>> >> Is it , this is not the solution I >>> >> need. I want that the user don't have a cross session and continue with >>> >> his session. Another matter is that my php session timeout is too small. >>> >>> JP> So turn it up. It's a setting in the php.ini. >>> >>> >> I'm thinking change the Auth mechanism to a LiveUser autentication >>> >> system. >>> >> Do you reccomend it? My problems can disappear if I use LiveUser and not >>> >> Auth? >>> >>> JP> No idea, sorry. If the problem is with the PHP session handler, >>> JP> changing to a different system is unlikely to help. >>> >>> JP> Are you using the normal file-based PHP sessions or DB sessions? >>> >>> >>> >>> >> >>> >> Thanks >>> >> >>> >> >>> >> >>> >> > On Thu, 18 Nov 2004 21:02:21 -0000, subs <subs@snackfood.org> >>> >> > wrote: >>> >> >> >>> >> >> >>> >> >> > On Thu, 18 Nov 2004 14:04:32 -0500, Erik Heerlein >>> >> >> > <erik@erikheerlein.com> wrote: >>> >> >> > > That IP validation may be a problem if the user is on a AOL >>> >> >> > account as >>> >> >> > > an AOL users IP can change on the fly. >>> >> >> > > >>> >> >> > >>> >> >> > Are you absolutely sure of that? Dial-up users' IPs can >>> >> >> > change between dial-ups, but I doubt they're going to >>> >> >> > change >>> >> >> > on-the-fly. If they did, the internet simply wouldn't work. >>> >> >> > >>> >> >> > Unless, of course, they're using some kind of round-robin >>> >> >> > proxy system, but usually a user gets directed to one and >>> >> >> > stays there for the entire session. >>> >> >> > >>> >> >> >>> >> >> Some proxy clusters will often present a number of different >>> >> >> addresses >>> >> >> to a >>> >> >> remote server during a session. Any authentication/authorization >>> >> >> mechanism >>> >> >> which relies on REMOTE_ADDR is generally a bad idea IMHO. >>> >> >> You could add a user_id field to your sessions table and do the >>> >> >> equivalent >>> >> >> of "DELETE FROM sessions WHERE user_id = <user_id> AND >>> >> >> session_id != >>> >> >> <new_session_id>" after each successful login (assuming >>> >> >> you're using a >>> >> >> DB >>> >> >> session store). Shouldn't be too hard to hook this in somewhere. >>> >> >> >>> >> > >>> >> > Yeah, but the point is that the session is being hijacked. If this is >>> >> > the case, it's almost certain that the user has the same session >>> >> > cookie/id, so this wouldn't help. >>> >> > >>> >> > -- >>> >> > Justin Patrin >>> >> > >>> >> > -- >>> >> >>> >> >>> >> > PEAR General Mailing List (http://pear.php.net/) >>> >> > To unsubscribe, visit: >>> >> > http://www.php.net/unsub.php >>> >> > >>> >> > >>> >> >>> >>> JP> -- >>> JP> Justin Patrin >>> >>> >>> VD> -- VD> Salutacions, VD> Leo Márquez VD> [ Enginyeria del software / Internet ] VD> [ Calidae - www.calidae.com ] -- Salutacions, Leo Márquez [ Enginyeria del software / Internet ] [ Calidae - www.calidae.com ]