Serge Sozonoff wrote:
>
> Hi Joshua,
>
> I was wondering if you could give us a little update on the status of
> Sessions w/o cookies for Apache::ASP?
>
> Have you started coding it already or is it at the bottom
> of a big list of things to do?
>
> Many Thanks,
>
> Serge
>
I have been working with Remi Fasol on this, and what we
have so far is a set up that uses the QueryString for
keeping track of session ids, in addition to the cookie
implementation that exists.
The QueryString method represents nice backup to the existing
cookie implementation for users that have cookies turned off,
but functionally is not as nice because someone will get a
new session id when reentering the site. So if a user starts
browsing off site, and instead of hitting the back button,
just reenters your URL in the location bar, they will start a
new session. Remi commented that Amazon's sessions seem to
have the same limitations.
These cookieless sessions are implemented with a config setting
SessionQueryStringID that if set, ASP will automatically parse
out of the QueryString the session-id, and use that if there
is no such session-id cookie. Then, whatever URL's you
want the system to keep track of, the web developer uses the
$Server->URL($url, { %params })
API extension to create a URL that will have a session id
built into it. This $Server->URL() method will be nice
for just building URL's in general with or without the
cookieless sessions, as it will joing the params hash
into a nice ?query_string automatically.
It reoccured to me just now (back from a sessions
methods discussion a long time ago) that these query string
cookies might show up in the referer logs of other sites if you
have offsite links on your session id pages. I tried a workaround
just now where a redirect program would handle offsite links, but
the HTTP_REFERER is sticky to the last page visited, and I see
no workaround to this security issue.
What options are there anyone, for real cookieless sessions,
without this security risk ??? We can't use IP authentication
because of proxies/NAT, maybe an SSL cert, but not everyone has
this, the UserAgent is not stratified enough to mean much,
so that what, when we are trying to get past cookies here.
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
