First of all, why do I need cookie? My SIDs are 32bytes long so guessing it could be a bit of a PITA. And if someone would sniff the SID, he could set his browser's cookies to send this SID. So I don't understand how cookies might help? [especially that they are sent from a potentially untrusted user]
And about relative links, I guess that using <BASE HREF="http://www.domain.com/sid0123456789ABCDEF";> should solve relative this problem as well :-) Dave Weis wrote: > This ends up being quite a pain. My current employer's site works like > this, www.businessolver.com. Doing relative links in everything is no fun, > especially static html. You do need a cookie along with this method or you > are vulnerable to session highjacking. > > dave > > On Thu, 27 Dec 2001, Wojciech Kocjan wrote: > >>I realize that this idea is quite weird and probably useless, but what >>if sessions on AOLserver would be implemented in this weird way: >> >>/ created/gets (cookie - if available) a SID and redirects to >>/ssn0123456789abcde/index.adp which is the real page from documentroot >> >>this way, tracking sessions can be done via an url - assuming that noone >>will use [ns_conn urlv|urlc] in unproper way and won't redirect >>forms/links as /link/to/page.adp. >> >>This could be written to handle only /ssn* and / (to get the cookie >>and/or redirect to session-tracked url). The problem is that this won't >>work with registered procs and would require distinguishing ADP files >>and change /directory/ to /directory/index.adp and so on. But it is wort >>h considering... >> >>-- >>WK >> >> > > -- > Dave Weis "I believe there are more instances of the abridgement > [EMAIL PROTECTED] of the freedom of the people by gradual and silent > encroachments of those in power than by violent > and sudden usurpations."- James Madison > > > >
