On Tuesday, November 13, 2001, at 10:17 AM, Ken Jones wrote:

> On Mon, 2001-11-12 at 16:39, Tom Collins wrote:
>> At 7:15 PM -0600 11/11/01, Bill Shupp wrote:
>>> Since the session id would need to be stored in all URLs and form,
>>> this is where most of the work would be in converting qmailadmin to
>>> use session ids rather than IP addresses.
>>>
>>> The good news is that qmailadmin would remain cookie free.  I just
>>> implemented a similar scenario in PHP4 with its new session support.
>>> Seems to work pretty well.
>>
>> Why is storing the session id in the URLs/FORMs preferable to a
>> session cookie that expires when the user quits their browser (or
>> "logs out")?
>>
>> It seems like it would be a lot of work to modify the URLs and FORMs
>> through qmailadmin as opposed to modifying the code that
>> authenticates the session.  That session id could leak into the
>> Referrer field if there are any "off site" links that appear in
>> qmailadmin.
>>
>> Aren't cookies supported in most browsers (at least any capable of
>> displaying the qmailadmin interface)?  Could you fall back on
>> IP-based sessions if the user is unwilling to accept a cookie?
>>
>> cookies != evil
>
> Unfortunately for many people, cookies == evil
>
> That's why we first wrote qmailadmin the way it is.
>
> Ken Jones

The *only* issue with the current session mechanism is with people  
whose IPs change.  Otherwise, it's fine.  And for those whose proxy 
properly sets the HTTP_X_FORWARDED_FOR environment, this is no longer an 
issue.  But some don't have that set.   I'm just looking around at other 
options to solve this issue to it works for *everyone*.

I tend to like the session id idea, but can't think of a good way around 
the potential "referer leak" mentioned earlier.  Perhaps someone has a 
better idea...

Regards,

Bill Shupp

Reply via email to