On Tue, 02 Nov 2004 17:23:16 -0500, Michael <suppressed> wrote:
> Cees Hek wrote:
> > What I would do in this case is use the username as the session ID.
> > This will work if your sessions are only used for logged in users. It
> > will allow you to find the session that belongs to a specific logged
> > in user, and guarantees that there will ever only be one session per
> > user.
>
> I could be wrong, but that seems really insecure. After login, the user
> could change their cookie (or session id) to be some other user's name
> and then masquarade as the other user (changing passwords, settings,
> seeing confidencial data, and other general mucking around). Since user
> names are usually based on names and email addresses they should be
> *really* easy to guess.
Well, you shouldn't depend on a cookie to figure out what the username
is. You use $ENV{USER_NAME} which is not editable by the end user. I
probably should have mentioned that, 'cause you are right, it can be
very insecure if implemented incorrectly.
If you don't have $ENV{USER_NAME} then you can do it with 2 sessions.
Do a standard session based login. That session should be able to
identify what user is logged in. Then open a second session using the
username as the session ID and use that as the real session for any
persistent variables. The first session is purely to handle the
login, which will then point you to the real session.
Cheers,
--
Cees Hek
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.