Maybe something like "identifier" could work? Sent from my Nexus One On Nov 2, 2010 8:58 AM, "Fabien Potencier" < [email protected]> wrote: > On 11/2/10 4:48 PM, Georg wrote: >> 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. > > That's why I have used username instead in the first place ;) > > Fabien > >> >> 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]<symfony-devs%[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]<symfony-devs%[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
