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