[drupal-devel] remote auth and required email/password fields

[Gerhard Killesreiter]

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 at 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 at 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