[geeklog-devel] Sessions, again

[Tony Bibbs]

Dirk Haun wrote:

> <>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.

The code base for this is small.  That said, I can probably get some of 
the bug fixes I have already implemented into it and re-release it.  
Another option is to simply write our own session handler which is quite 
trivial (even for storing stuff in a database).  That way you get rid of 
the PEAR requirement and give lib-sessions a much needed upgrade.  
Regardless, I think the session handling in Geeklog is archaic at best 
and needs revamping.  Whether we do it here now or in a another release 
is up to you guys.

> <>
> 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 
> ...).

I'll double check on this.  Again, small code base so fixing this isn't 
an issue.  I'm assuming the write you are seeing is when it is writing 
the Session ID to the cookie, right?  That's the only thing I can think of.

> <>
> 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?

Again, small code base.  It's probably as easy as ripping out the IF 
logic that enables that.

> <>
>
> 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'm less pessimestic.  I think with all the changes and the 
register_globals stuff we should take our time, call this release 1.4 
and move on.  In fact, I'd say we could probably have something we 
haven't had in a while, a beta release.  Just a suggestion.  I'll work 
with Blaine on the session stuff and see if we can't get it all ironed 
out.  If  you decide to rip it out of CVS, please give a heads up so I 
can bring a copy down just prior.

In the meantime I'll be busy getting the to-do items off my plate over 
this holiday weekend.

--Tony