On Fri, 2004-05-28 at 05:59, Paul Boddie wrote:
> Ian Bicking [mailto:ianb@...] wrote:
> > There's nothing canonical at this time -- UserKit isn't really
> > canonical.
> Inspired by various authentication products (and mechanisms in earlier
> systems I've worked with), whilst leaving out the big iron requirements
> and arcane configuration rituals, I recently wrote some simple
> components for WebStack which let you "guard" an application by
> redirecting unauthenticated users to a login screen URL; that login
> screen then does the appropriate authentication before redirecting you
> back to the application (with the necessary authentication token stored
> in a cookie). It isn't tested with Webware yet, but when I get round to
> that, I'm almost certain it will work. ;-)
> I suppose that, just as was discussed/described on the Wiki once upon a
> time, there are a few different sides to the story: having a convenient
> login mechanism, checking user details against some kind of database,
> being able to conveniently verify a user's authentication state, and
> access control (which is a whole big area in itself). I'm not familiar
> with UserKit at all, but it would be nice to resolve this area of
> uncertainty (with the exception of access control, probably) once and
> for all.
LoginKit is based on some stuff we (I think that would be Mike Orr,
Tripp, and I) worked on a tad like a year and a half ago. Basically it
defines an interface for a "user manager", which can get "user" objects
(which you define on your own) and can check passwords and the like.
That basic portion tries to be really vague, in that it doesn't specify
much about the user object and the user manager is pretty minimal.
But... when I implemented other parts of the system, like forgotten
password, user management web interfaces (delete, edit, etc.), and
eventually role management, the actual user object's interfaces becomes
more important. It would be a good place for interfaces and adapters,
Anyway, it's as minimal and agnostic as I could make it. Then there's a
bunch of Webware servlet tie-ins to handle the mechanics of logging in
and so forth, which don't need to be nearly as agnostic, and some
permission hooks, which are very vague (mostly you can just raise the
right exception for permission denied). "Access control" tends to be
too loaded a term in my mind -- servlets aren't "resources", and access
control usually has to work on a finer-grained level than servlets.
Mostly this isn't an issue so long as the permission system is
imperative -- then you can put in any logic that you want to control