Max Kellermann wrote:
>
> On 2005/09/22 14:11, Eli Marmor <[EMAIL PROTECTED]> wrote:
> > By the way: it may be based on libapreq2. And if I come into it,
> > then what about the following idea: to add some authentication
> > functions to libapreq2; In any case, it already does most of the
> > work, including GET/POST parameter manipulation, as well as cookie
> > manipulation.
>
> I believe we should not add anything about authentication to libapreq.
> It is currently a generic request parser, and should stay so. Adding
> authentication would require to make assumptions about the
> authentication procedure, which in turn forces users to follow our
> assumptions.
>
> There is no disadvantage in implementing authentication in an
> additional library.
Sorry for being not enough clear: I didn't speak about HTTP
authentication, and even not about a library doing the authentication
for you. All I spoke was about some convenient routines that may save
80% of the work for people who implement cookies-based or session-based
authentication.
And I'll add a brief explanation for people who don't control exactly
how this authentication works:
The username and the password are received from the user by a POST
request, optionally encrypted (by SSL, or by JavaScript, etc.). From
now on, the programmer "marks" the session, so following requests will
be identified as coming from this specific user. This can be done in
two ways: by setting a unique cookie (usually temporary), or by adding
a unique hidden "&arg=val" to following requests/responses
("sessionization").
There must be a special URL/module/whatever for logout.
Cookies may be not temporary, so following accesses to the site, will
cause the "username" field of the login form to be initialized with the
value from the previous time (of course, this is optional).
While it's easy to describe this mechanism, its implementation (without
the help of any library) is hard. Implementation based on a library
like libapreq2 saves the effort by at least 50%. All I suggested was to
add some convenient routines that will ease this effort further. For
example, a function to create an encrypted code to be used as the
unique cookie or session-id. Or obtaining the code from a request. Or
getting the username out of a request struct. Or using the input filter
to "consume" the session-id from the QUERY_STRING (or the POST params)
so filters/modules following in the chain will not see it.
This extra API is so thin, and will be very easy to code, because most
of its work is already done by lower level functions of libapreq2.
--
Eli Marmor
[EMAIL PROTECTED]
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.: +972-9-766-1020 8 Yad-Harutzim St.
Fax.: +972-9-766-1314 P.O.B. 7004
Mobile: +972-50-5237338 Kfar-Saba 44641, Israel
