The Toolkit for Online Communities
17204 Community Members, 0 members online, 2095 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : RFC: External Authentication : One Message

Forum OpenACS Development: Re: RFC: External Authentication

Posted by Lars Pind on

Thanks a bunch for your feedback.

Re authority. Okay. I actually favor authority as well. Should we have a vote? :)

Login screen: That's Amazon's login page, which I like a lot. We could make it an option. I've heard the requirement for email-less logins frequently enough that I think it would be good to honor that. Also, in a heterogenous environment where all the other systems ask for username, that'll be easier for people to understand. But we could surely make it an option.

Regarding the "auth::authenticate -username -domain -password -secure:boolean" vs. "set user_id [auth::get_user_id -require_valid_user:boolean]": My scheme does the same thing, but without touching the every page in the system :)

Your function:

set user_id [auth::get_user_id -require_valid_user:boolean]
corresponds precisely to
set user_id [ad_conn user_id]
In my section on single-sign-on, I actually suggested the auth::require_login could redirect to a CAS server instead of to the local /register pages. Doesn't that solve that problem?

What I don't understand about your auth::get_user_id function is that it looks like it will redirect the user's browser to a login page, and conduct that whole page flow, all while the code calling this function is on hold, waiting for its return value, which it then gets when the user is done with the login process. Now, we all know that isn't possible. In reality, the function would send a redirect to the browser, then throw an error, which will cause the thread to stop executing. Then after the user continued the entire login sequence, our page would get requested by the browser again, and the auth::get_user_id would get called from the top again. At least the good old "ad_maybe_redirect_for_registration" makes it obviously clear what is really going on.

Yes, we can definitely make the Authentication API itself a service contract, for which you can supply different implementations, and I think it's a good idea to do so. But I've decided on an approach with more framework to make it easier to use without hand-coding being necessary. And that may push that layer of indirection off to a later date. Unless, of course, someone requires this feature today, in which case I'll be happy to hear from them :)

Security: That's the way it is. If you want something more secure, there's nothing stopping you from using CAS, no?