On Tue, 18 Mar 2003 16:17:06 -0800 (PST), Brion Vibber
<vibber@aludra.usc.edu> wrote:
(narrowed to wikitech-l)
>
> Our whole login/cookie system is crying out for improvement. I've never
> messed with it much because I'm not 100% sure how it works. ;)
>
> We partially use PHP's session management, and we also set some other
> cookies. I don't know what the default timeouts are. PHP session cookies
> are IMHO problematic, because it asks to set a cookie *the first time you
> touch the site*. I'm sure I'm not the only one who blocks all cookies by
> default unless I'm deliberately logging in to a site; and we do not
> gracefully handle the case where someone tries to log in with cookies
> disabled.
>
PHP session
> stuff has some funky link munging, but a) we prevent them from being put
> in on most pages by using absolute URLs, and b) with our current url
> rewriting configuration the information would be lost in most cases. And
> c) putting session information into URLs is *serious* bad mojo, with
> great
> possibilities for session hijacking.)
>
>
Thanks for the detailed explanation Brion.
Alas, I develop Miva/Dbase rather than PHP/SQL (terminology nearly got me
there - In my last project I would say we ran 35 databases, whereas in SQL
it would probably have been one database with 35 tables)
I share your pain regarding maintaining session state without cookies. Miva
also has a sessionid which is unique to IP number and browser and which
persists if you allow its cookie. The only way I can see of doing it
without cookies is to MD5 the IP address when a user without cookies logs
in. You could pass that in an URL and revalidate it against the IP number
on each page, but for a site like Wikipedia that's an awful lot of 32-
character strings to serve with each page!
--
Richard Grevers
<vibber@aludra.usc.edu> wrote:
(narrowed to wikitech-l)
>
> Our whole login/cookie system is crying out for improvement. I've never
> messed with it much because I'm not 100% sure how it works. ;)
>
> We partially use PHP's session management, and we also set some other
> cookies. I don't know what the default timeouts are. PHP session cookies
> are IMHO problematic, because it asks to set a cookie *the first time you
> touch the site*. I'm sure I'm not the only one who blocks all cookies by
> default unless I'm deliberately logging in to a site; and we do not
> gracefully handle the case where someone tries to log in with cookies
> disabled.
>
PHP session
> stuff has some funky link munging, but a) we prevent them from being put
> in on most pages by using absolute URLs, and b) with our current url
> rewriting configuration the information would be lost in most cases. And
> c) putting session information into URLs is *serious* bad mojo, with
> great
> possibilities for session hijacking.)
>
>
Thanks for the detailed explanation Brion.
Alas, I develop Miva/Dbase rather than PHP/SQL (terminology nearly got me
there - In my last project I would say we ran 35 databases, whereas in SQL
it would probably have been one database with 35 tables)
I share your pain regarding maintaining session state without cookies. Miva
also has a sessionid which is unique to IP number and browser and which
persists if you allow its cookie. The only way I can see of doing it
without cookies is to MD5 the IP address when a user without cookies logs
in. You could pass that in an URL and revalidate it against the IP number
on each page, but for a site like Wikipedia that's an awful lot of 32-
character strings to serve with each page!
--
Richard Grevers