[geeklog-devel] Sessions, again

Dirk Haun dirk at haun-online.de
Thu Sep 2 17:12:05 EDT 2004


Guys,

I've installed the CVS code on my normal webspace today for the first
time. So I don't have that much control over that setup as I have
elsewhere. I found a couple of issues with the HTTP session stuff that
annoyed me

1. I usually use the PEAR installed on the server, not the local copy.
Since the HTTP sessions are in beta, they are not part of a standard PEAR
install and I have to use the PEAR classes that we ship with Geeklog.

Something is wrong with our approach here. The PEAR guys are pretty picky
(ask Tony), so when they haven't released HTTP session yet, there must be
a reason for this. Plus I can foresee the support issues this extra class
will cause us.

2. When browsing the site in Lynx, I was asked twice to accept cookies.
Once for www.example.com and once for .example.com. The latter is normal
- that's for Geeklog's cookies. The former must come from the HTTP
sessions class then and it seems to be using a different domain name.

Is this configurable in the sessions class? Otherwise, it'll add an extra
level of annoyance for people who are picky about cookies (like myself ...).

3. When validating the HTML of my site, the validator complained (and
rightly so) about session IDs that were inserted in the HTML! Since the
W3C validator, <http://validator.w3.org/>, doesn't accept cookies the
session code seems to fall back to using session IDs in the URLs, e.g.

    .../index.php?topic=music&SessionID=vp4137881690fd2

The problem here is that (as part of a link) it should read &
SessionID=... This is actually a configuration issue in php.ini, but on
shared web hosting, you often don't have the permissions to change that.

Why is the sessions class injecting session IDs in the code anyway? Is
this configurable?


Overall, I have to say that I'm not too pleased with the current state.
I'm actually pretty close to ripping it out of CVS again.

I see the potential benefits for using PHP sessions, but something about
our current approach seems to be wrong ...

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/




More information about the geeklog-devel mailing list