[phplib] Auth: I will not give up on this From: giancarlo pinerolo (giancarlo <email protected>)
Date: 08/12/01

Auth is by its nature 'site-wide'. There is few doubts about this. I am
even thinking of cross-site auth... Application-wide auth makes no
sense, unless you have only one application on your site, and it uses
auth.

It is full of examples of modules that provide for application to rely
on some preexisting auth mechanism:
/etc/passwd, Kerberos, Radius, RSSA auth delivered to httpd, cvs, ftp,
login, POP3, IMAP etc etc.

Because once you have one auth in place, it is normal and desirable that
you want to use it for more than one application.

Auth is also one of the core features of phplib. Phplib provides auth to
phplib-based web applications, and maybe aspires to provide it to PEAR.

Then my question is: what hooks does phplib's auth offer to multiple
phplib-based applications? Or, turn it the other way round, how do
phplib-based applications hook on to preexisting phplib auth?

This is not a architectural-design divagation, it is a very practical
and reasonable ond frequent need.

even in its more elaborate forms, auth is something that comes out with
nothing more than a 'Yes' or a 'No', and , it will reply you 'Yes' or
'No' to question of the type :
'is he who he pretends to be, part of the group he pretends to be, with
the privileges he preteds to have?' Reply Yes or No.

Does the solving of this integration problem belong to application
design? In my opinion no. Application designers must know how to make
their application hook onto most phplib auth implementations. Stop.
They should not choose to accompaign their application with a full blown
ad-hoc auth, but just give a few hints on how to extend a default
phplib auth.

The solution to this problem has to be provided by phplib. Auth is not
something an application should even worry about, other than for: how to
pose the correct answer, how to get back the 'Yes' or the 'No'. Nobody
should be faced with the problem of how to properly extend classes,
especially if it now starts to adopt that flexible grouping/permission
scheme suggested by KK. Just how to pose the right question and get the
answer. Think of this as a client-server mechanism, and it will help.

In my opinion phplib auth, as it is now, is only for one-application
use. This is its major fault. Its inner design is very extensible and
flexible, and for this I think it would not be hard to make it widely
adoptable by multiple applications, usable. But as-of-now it is not, and
in this it misses a major issue inherent in the concept of Auth itself.

What do you think?

Giancarlo 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>