Re: [Phplib-users] Doc suggestions

[Kristian K. <kk...@ne...>]

Am Dienstag, 9. Juli 2002 15:54 schrieb Giancarlo:
> -don't you beleive that, among these various propagations,
> cookies offer more guarantees=20

There are two known general modes of ID propagation. These are=20
cookies and making the ID part of the URL. The latter is always=20
deprecated, as the ID becomes part of the URL, that is, becomes

a) visible
b) logged in many proxies
c) part of bookmarks
d) is probably being mailed when a URL is mailed by a user.
e) is lost when the users browsed to a different target and later=20
returns.
f) is leaked out of the application via referer

The URL can carry an ID in three known places. These are GET=20
parameters (http://server/path/program?ID=3D...), path components=20
(http://server/ID/path/program), and hostnames=20
(http://xID.serverdomain/path/program). All of these have=20
distinct advantages and disadvantages, and all of them are=20
subject to the risks a-f shown above. Koehntopp PHPLIB only used=20
GET parameters, as they did not require special server setup=20
procedures, no special DNS setup and are not patented. It is=20
only a fallback mechanism anyway, and not worth bothering more=20
than absolutely necessary.

So an application should always try to use cookies and only fall=20
back to URL propagation if necessary.

>-is it right  to downgrade
> everybody's security to the minimum common of those  who have
> cookies disabled, whith an effect exactly opposite of their
> reason to do so. Shouldn't it be more right then to confine
> that to only those who cannot afford a better way?=20

See discussion above. Cookies are the recommended way to=20
propagate an ID, and should be used wherever possible. Note that=20
you probably have to provide a valid P3P policy in order for=20
current MSIE to accept a session cookie.

>-what other
> session mngmnt allows arbitrary id creation and what can be a
> honest use of it?=20

None. Arbitrary ID creation was an accidental artefact of the=20
Koehntopp PHPLIB implementation. In fact the original code=20
should have checked for the existence of a session with that ID,=20
and created a new ID if there was no session record present with=20
the original ID. I remember thinking about that case, and then=20
dropping it for performance reasons (that was using MySQL based=20
sessions on a 143 MHz Ultra-Sparc 1).

>-what about issue a new session and move to
> it after authenticating?=20

Why should that be useful? Sessions and authentications are=20
different and independent things and should have only little=20
interaction.

>-what about keeping track of sess
> creation date & initial mode,  and  consider a change of mode
> at the same level as a new client (mode coherence?).=20

Sorry, I am missing the previous discussion here. What exactly=20
are the problem and idea behind this?

>- what is
> the use of the auth['uid']=3D'form' status, if not better
> security?

Koehntopp PHPLIB was programmed with interstitial (blocking)=20
authentication in mind. The state machine is really only useful=20
for that, and little else. Default Auth and auth_preauth() were=20
added as an afterthought in Koehntopp PHPLIB, and are really=20
cluttering up the Auth process.=20

The whole thing should be redesigned, and using a sidebar login=20
and default authentication as the main model, as this is much=20
more common and useful than the original interstitial auth.


Note that I am not longer involved in PHPLIB development at all,=20
am no longer using PHP very much, and am reading this list only=20
sporadically. So this are just the ramblings of some old guy who=20
left you with some original code...

Kristian