Just two additional thoughts:
At 14:18 Uhr +0100 24.2.2000, Mark Ferraretto wrote:
..
>I find cookies easier personally, especially has they have a built-in
>expiry mechanism. Good for timing out logins.
NO, as far I understand, that would NOT be good for timing out logins. For
my understanding, the expiration date of cookies is only that the browser
deletes them after a given time, and it doesn't prevent someone to use the
same cookie (without the expiration date) still afterwards. So you have to
track cookie expiration times on the server anyway.
At 22:38 Uhr +0100 24.2.2000, James Treworgy wrote:
>At 10:32 PM 2/24/00 +0100, harm wrote:
>>No, that is not the case.
>>_before_ you generete the index you create a session. Sure, you have to
>>generate all pages with links dynamicly, but in these days with perl,php,
>>asp, mason etc, this should not be such a big problem. You could
>>use some url rewrite sheme like http://my.site/do.this.html/<sessionid>
>>just as easy, couldn`t you?
>
>Ah, hadn't thought of that! That would work. I didn't generate a session
>for my site until a user logged in but I guess theres no reason why I
>couldn't make one as soon as they hit it. I'll probably set that up.
>
Even if you serve the first page with sessionid's in it's links, the
sessionid would be lost if the user hits reload on the first page, or the
browser requests this page again for another reason (newer netscape seems
to have a strange caching mechanism, reloading pages more frequently than
necessary). To solve this, I've just had two ideas, which I haven't tested
yet (but will do in near future):
a) tell the browser to keep the old page if he has one (depends on the http
request, I don't know this in detail now)
-or-
b) use a redirect from the generic URL (my.site/ ->
my.site/script/sessionid/). This way, the first page the user sees has
already the session in it's own url. This assumes that the browser doesn't
request 'my.site/' again. A small optical drawback (or a plus, depends on
your perspective) is that the user sees the sessionid stuff in the url
field of the browser even if you use a frameset (otherwise, the 'clean' url
of the frameset would hide the url's from the sub-documents).
PS. depending of the application, a drawback of using Cookies could be that
a user can't open multiple windows and have different sessions in each of
them. (Or, said otherwise: a cookie is for identifying a _user_, not a
session. For identifying sessions, you should use url's.) (This is just my
idea, I don't have much experience with that stuff yet)
.Christian
