On Wed, 16 Mar 2005, Moshe Weitzman wrote:
I can see one problem arising from the profile edit page's current design. What happens when a user changes their name from "user@authserver" to be just plain "user" (or vice/versa)? Will that same account no longer be authenticated against the remote server?
Right.
Wrong. The authmap table maps the remote username to local uid. Look at the source in user_login()
Right, I was wrong. The code is in user_authenticate.
I dob't get what you want to do.
What happens to normal, locally authenticated users who change their username from "someuser" to "someuser@someotherauthserver"?
you can't put an @ in your username unless you register via remote auth
user_validate_name would not complain. Just tested it locally, works fine.
Not much, local auth is always used as backup.
How would they ever get logged back in if they changed their username to, say, their email address? (I'm sure this has happened before)
again, we don't allow this.
Apparently we do.
Many auth servers provide full name, email address, etc., but there's currently no way of attriibuting these values to a local account. What about changing the hook_auth mechanism so that profile data collected at the time of signup can be applied to a new user's account.
we already have this capability in foaf.module. That module takes advantage of hook_user('login'). Once you see that module, and read up on user.module, I think many of your doubts will be answered. You can use hook_user('login') too with these auth servers if they don't use foaf.
This has been discussed in the "social software" session at the code sprint. The problem is to establish a connection of the remote server's fields to local Drupal fields (for example: we use "name" for the Drupal name, another software could think that is the given name).
again, see foaf module. it does this mapping
Right, was that mentioned at the meeting?
An idea (proposed by somebody else) for secure remote auth would be to let the user authenticate at the "home server" and only send a "yes" or "no" to the remote server. The remote server would pass the session ID along and get it back if authentication was succesfull. I am not completely sure, if this process is safe from exploits, though.
see http://alec.bohemiandrive.com/perm/2005/02/18/distributed-
Yeah, that was the link.
authentication for the vision of where we intend to go with this. noone has volunteered to code it yet.
That's the problem with all the nice ideas.
Ideally, the whole process should be encrypted.
not necessary.
That is why I wrote "ideally". ;)
In general, the whole remote authentication process is not of much value (at least to me) as long as there is no way to have a closed set of sites that can build a trusted network.
yes there is. you can use sso.module if you have a central
Will have a look (the module isn't available in head).
authoritative drupal site for identity. or if all sites share a database server, you can use a solution as described at http://lists.drupal.org/archives/drupal-devel/2004-07/msg00737.html.
Will read that up.
but even if you just have a bunch of independant trusted sites, you may employ username validation rules to shut out untrusted servers.
Ah, yes, I had forgotten that. Maybe we should write a book page about that.
I also rather create a new account because firefix remembers my passwords for me and the remote auth process has thus not much benefit for me. ;)
this is strange logic (especially for a scientist). firefox will remember passwords whether they are local or remote. it is just a textbox as far as it knows.
Well, to do remote registration, I'd need to remember my drupal.org password. Since ff does that for me, I don't bother to do that. I can't find a flaw with that logic. :o) (Yes, I could look the pw up in the password tab, but just registering anew is faster for me). Cheers, Gerhard