Hello, Sergei.
Sergei said:
> Hi Gustavo!
>
> > Yes, it sounds sensible. Another common alternative would be to provide a
> > registration form for LDAP and OpenID users in order for you to gather
> > all the metadata available in the back-end and ask the user to provide
> > the missing data (if any) -- of course, unlike normal registration forms,
> > you wouldn't request a password for the account. I think both options are
> > basically the same thing.
>
> Registering a user from an external auth source is incorrect by
> design, I think. This eliminates half of the benefits of OpenID
> logins, for example. You just login and everything (or moslty) else is
> done in the background without your interaction.
No, it depends on what you want to do. OpenID has never been meant to avoid
registration forms, just to do authentication.
It's perfectly valid and common to have registration forms for new OpenID
users, even if they call it "first-time login forms" (which is apparently a
normal login form, but upon successful login, the first time you're prompted
for account settings -- like those you find in registration forms). Not all
the data the consumer needs is or can be provided by the provider.
Actually I can't think of a single benefit lost by doing this.
That being said, some sites do not require additional data from the provider
and thus it is not necessary to bother the user with additional questions.
That's the kind of sites that don't use registration or "first-time login"
forms.
> > 1.- Ask new LDAP/OpenID users to choose a username for the site, which
> > then you'll store in your users table (again, with no password).
>
> Really, a 'login' is required only for 'local' users, not for
> extrenal. In most cases we need a nickname or a fullname, where a
> nickname could be a equal to their login for local users.
Oh, I see. Then you certainly may need a registration form for them.
> > Plus, there's no repoze.what LDAP plugin yet :)
>
> I hope there will be one some day? ;-)
Yes, why not? However, it's unlikely that it'd be me... Unless I need it, of
course :)
> > I'd treat them all like just one kind of users. They would all have a
> > record in the users table, which would look like this:
> > - user_name (PK).
> > - authn_backend ("openid", "ldap", "db").
> > - authn_key.
> > - email.
> > - full_name.
> > - ... the other columns...
>
> I'd ise:
> - id (integer PK - they are still faster!)
> - userid - a login for local users, and external source for external
> ones; external users just have protocol specification like http:// or
> ldap://
>
> > Where the value of "authn_key" will depend on "authn_backend":
> Or it's just a password for local users of empty for external (well,
> we have a policy to prevent empty-password users from logging in? :)
Yes, in your situation it'd be better.
> Anyway, I'll say it again, it's better to allow the external user to
> 'just login' and fetch his personal data into DB on each login for
> using it offline. That data could be loaded automatically into the
> User object, that is accessible via request.identity['user'], so we
> can always say "Hello, Full Name, welcome back" and never stick to
> custom metadata providers (we use them only to fetch that metadata at
> login time and save to the database)
Yes, now that I better understand what you want, I think that's the way to go.
Cheers!
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
