Thank you very much for all this information. This is much appreciated.
If we were to rename username to something else, I think principal makes the more sense, as this is what is used by Spring.
Fabien -- Fabien Potencier Sensio CEO - symfony lead developer sensiolabs.com | symfony-project.org | fabien.potencier.org Tél: +33 1 40 99 80 80 On 11/2/10 3:12 PM, Jeremy Mikola wrote:
Sorry if I'm late to the discussion, but better late than never. I support something generic such as UserIdentifier or Principal. With a number of Symfony1 projects under my belt, and now some Symfony2, I've seen plenty of cases where a username was not the only or even preferred method of logging in (vs. email, OpenID, OAuth, etc.), but the common denominator was always the user's ID. After working a bit with Jasig's CAS project (single sign-on system in Java/Spring) and implementing a Symfony2 bundle for it, I came to appreciate their notion of a principal. When you login to the CAS server, you typically provide a username and password combination. CAS doesn't assume that the username field is your principal -- it leaves that up to you to configure. At OpenSky, we needed to support username/email in the "username" field to be flexible, so our principal ended up being the user's GUID. The first step of CAS's login process is to utilize a PrincipalResolver service that takes some input (arbitrary username/email in our case) and converts it into a principal (GUID for the user account in our case). After this step, the password input and principal are then verified using a separate service in CAS. As you might expect, this requires at least two DB queries; however, it offers a great deal of extensibility thanks to DI. If you consider an authentication system using nothing but Facebook Connect or some other third-party service, we might not even have a username or password available for an account, but we'd have a principal identifier for the user account in our database. I suppose that is exactly what would be stored in the session (thinking back to sfGuard). If I were integrating Facebook Connect into CAS, I'd simply create a PrincipalResolver service to take its input from FB's API and lookup the user ID in our database corresponding to the FB user's ID, if any. The password service would be a no-op. I apologize if this went off-topic, but I think this presents a legitimate reason for keeping things generic. And while I'd personally use the user ID as the principal, I think the developer using Symfony2 should certainly be able to configure the "principal" field (anything with a unique constraint would technically be eligible). On Thu, Oct 21, 2010 at 8:17 AM, Bulat Shakirzyanov <[email protected] <mailto:[email protected]>> wrote: My vote is for "principal" Sent from my Nexus One -- jeremy mikola -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en
-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en
