Re: Re[4]: [PEAR] session cross between users?

From: Date: Fri, 19 Nov 2004 17:41:11 +0000
Subject: Re: Re[4]: [PEAR] session cross between users?
References: 1 2 3 4 5 6  Groups: php.pear.general 
Request: Send a blank email to pear-general+get-15689@lists.php.net to get a copy of this message
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. > Yes, this would probably have been dealt with before now, but perhaps you've got the right (wrong) conditions for a new bug. Perhaps.... 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 > > > -- Justin Patrin

« previous php.pear.general (#15689) next »