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