session cross between users? SOLVED!

Hi again!, The problem is solved. It was a problem with Smarty and caching. Probably a Smarty bug? We have a page as product.php which have to show a product. The urls from differents users can be: product.php?id=334 product.php?id=256 Smarty catch the page from the first user (the faster) and serve the same page to the second. Smarty has not consideration to the querystring parameter? This list is not the place to ask it but I was needed to explain the end of this thread that has taken part a few persons. We have deactivated the caching os Smarty and the application works fine. See you. 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 >> >> >> -- Salutacions, Leo Márquez [ Enginyeria del software / Internet ] [ Calidae - www.calidae.com ]