Yes,
we use our own url-rewriting implementation of Apache::Session::DBI -
we just use method calls instead of hrefs
($ui->a_href('page.html','querystring','other stuff') ) which whop a
key=<Apache::Sessionkey> into the query string.
In addition, to time out sessions we added a timestamp field to the
sessions database, and run a cron job or daemon to wipe out all the ones
over a certain age.
Jay Jacobs wrote:
>
> I've been perusing the archives on the topic of cookie vs. url vs. user
> session tracking, and I can't find a solution that is 100% effective.
>
> Here's the scenario... using Apache::Session::DBI on a public site, where
> registered users can log in to get detailed information and "place orders"
> online. Non-registered users will get basic information and ideally
> should be able to "place orders" that will have no real effect on the site
> (i.e. shopping cart with no purchasing)
>
> Here's some major concerns I groked from the archives:
> cookies: disabled from proxies, or disabled for "security"
> user-based: wouldn't solve non-registered user issue, nor site-wide
> url: requires site-wide url-rewriting, insecure from HTTP_REFERER
> standpoint
>
> My thought is to try to verify it from ip but that breaks when proxies
> come from more than one ip (AOL), or when nat is in place covering
> multiple client systems. Also adding a lame security attempt, and put a
> timed expiration on the server-side session after an hour or so.
>
> I'm thinking of just relying on cookies, while not 100%, it's gotta be
> close to 80 or 90% which may be good for this project. But I figured
> others had faced this same issue and had an ample solution...
>
> Jay Jacobs
> LachNet Inc.
