I am just reading this discussion along, as I had no time yet to test symfony2 (shame, I know). I am strongly opposed against principal. The reason is that if you are not a java programmer (and most PHP devs are not), you have no idea what it means. I speak german, so I had to look it up, and it seems to describe either some economic chief function, or the head of a scool. But it is in no way related to it's function, the primary identifier of a user. So every new symfony2 developer that starts using the security layer would have to remember a proprietary word (of Spring and maybe symfony2), and googling or code completion for user identifier would not become easier. My 2 cents, please don't use an identifier that was named wrong in one package in symfony2, because it is used there. Use something intuitive.
Am 02.11.2010 15:24, schrieb Fabien Potencier: > 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
