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