Re: Refactoring Authenticated/Identified

Geert Bevin wrote:
> I think that this would be a very useful refactoring. Honestly, the
> tight bound between the deployer classes and the actual authentication
> elements has always somewhat bothered me. Actually, I can't believe
> that I never thought of doing this way. Then again, it has been awhile
> since I created custom authentication logic, so I can cut myself some
> slack. ;-)

Super, glad I'm not totally off the wall here. I have been doing some
custom authentication code on both of my current RIFE projects (totally
different on each, one is just the "remember me" stuff and the other is
a custom Authenticated subclass that sends the user to a third-party
authentication service to log in) so any movement in this direction will
make my life much easier.

What I'd love -- and I'm sure you would too -- would be to get to the
point where a reasonably skilled developer could write their own, say,
user database module without having to ever look at the RIFE source
tree. Not that there's anything bad about having the sources to refer
to, of course, but if my experience is typical, right now things are
intertwined tightly enough that someone writing custom auth code has to
be highly aware of the implementation details of the authentication system.

This refactoring, assuming it turns out to be as feasible as it sounds,
will definitely help in that area. I was not looking forward to figuring
out how to explain the current Deployer system on the auth internals
Wiki page. (Which, BTW, I am about to go work on a little more.)

> Of all the previous suggestions that you've made, I think that the
> fall-through authentication solution seems the best to me (the one
> that doesn't require a form when no authentication session is present
> and no remember cookie can be found). It doesn't solve the theoretical
> use case of people that want to retrieve user credentials of accounts
> that haven't been registered as users to the authentication back-end
> yet, but it does solve your "eternal authentication session" problem
> without introducing an artificial embedded element.

I'm not sure I understand that use case. Can you give me an example?

I've just filed RIFE-301 with an initial stab at an implementation of
the fall-through mechanism. Seems to work just fine.

-Steve

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel