From: | Andrew McMillan <andrew(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Christian Marschalek <cm(at)chello(dot)at> |
Cc: | beloshapka(at)mnogo(dot)ru, "[PHP] PostgreSQL" <pgsql-php(at)postgresql(dot)org> |
Subject: | Re: HTTP authentication |
Date: | 2001-11-16 10:26:20 |
Message-ID: | 1005906380.4156.2.camel@kant.mcmillan.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-php |
On Sun, 2001-04-29 at 05:44, Christian Marschalek wrote:
> > I just wrote an auth library that uses sessions and
> > stores passwords encrypted in the database. I am fairly new
> > to PHP (tho experienced in other web devel technologies) so
> > it might need improvements, but it works very well for me.
>
> I'm fairly new to PHP myself but I have like 4 years expirience with C
> and C++. I would check out if your library can be improved if you want
> me to.
>
> But for my project I'll use sessions without cookies because I can't
> rely on the users having the feature turned on in their browsers.
Don't forget that there are serious flaws in the URL rewriting approach
as well which are not present in the cookie approach :-(
Our company recently implemented a site where one of the more
egotistical coders was militantly anti-cookie and as a result we ended
up with URL rewriting (auth was not an option in this case).
As a result we ended up with people e-mailing (rewritten) URL's to
friends, or pasted (rewritten) URL's into ad serversand so forth. A few
days after we went live we had one session that was receiving a
substantial part of the traffic, and that session was saving user data
which was mutating in interesting ways.
On top of that, we finally ended up implementing cookies because it
turned out we needed more persistence of data than URL rewriting can
offer. The session code is _still_ crapola IMNSHO because it uses the
rewriting by preference, rather than treating the cookie as 'best'.
The PHP session code gets this _right_ by preferring cookies and falling
back to URL rewriting _if_it_has_to_ for those reasons.
Sure, cookies are some sort of security problem, but so are bookmarks
and history, not to mention page caches! If you wouldn't put it in a
URL, then don't put it in a cookie, by all means, but it is debatable
(and configurable) which hangs around on a users hard disk for the
longest. I know my browser history (i.e. URL coded information) is
currently set for three months, but if I get a session cookie it is gone
when I close my browser down - something I usually have to do every few
days.
All that I put in a cookie is an encrypted hashed value. Everything
else is derivable at the server end. I also only ever set one cookie,
and associate all information with that, again at the server.
Regards,
Andrew.
--
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201 MOB: +64(21)635-694 OFFICE: +64(4)499-2267
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Main | 2001-11-16 12:18:44 | Form Validaton |
Previous Message | Duncan Adams (DNS) | 2001-11-16 10:23:07 | Re: Re: Secure pages |