#symfony-dev IRC logs re: security component's user interface

transcript.txt

Nov 18 15:53:04 <digitarald>	there is no user class out of the box?
Nov 18 15:53:35 <digitarald>	ah, thats why there is so much session handling in the sample github apps
Nov 18 16:02:38 <digitarald>	oh man … why would UserProviderInterface require password and username
Nov 18 16:02:54 <digitarald>	I mean AccountInterface
Nov 18 16:03:19 <digitarald>	my frontend works against an API … and some stuff I expose is authenticated via OAuth …
Nov 18 16:03:24 <digitarald>	design fail
Nov 18 16:04:21 <digitarald>	nicely designed for doctrine … doctrine win. but since I don't have a db … me fail
Nov 18 16:22:13 <johanness>	digitarald: password shouldnt be required by a user provider
Nov 18 16:23:15 <digitarald>	guess I skup users and only uses sessions
Nov 18 16:23:19 <digitarald>	or extend the firewall
Nov 18 16:23:26 <johanness>	uhm?
Nov 18 16:23:32 <digitarald>	http://docs.symfony-reloaded.org/master/guides/security/users.html
Nov 18 16:23:36 <johanness>	why would you do that
Nov 18 16:23:43 <digitarald>	usernames … passwords
Nov 18 16:24:21 <johanness>	i dont see your point :)
Nov 18 16:34:53 <digitarald>	johanness: AccountInterface somehow requires password and username
Nov 18 16:35:06 <digitarald>	and UserProviderInterface loads by username …
Nov 18 16:35:20 <digitarald>	not sure why they should have these fields at all
Nov 18 16:35:56 <digitarald>	my previous sf 1 apps depended on AuthenticatedUser … and I handled if they would require a user or even a password
Nov 18 16:36:09 <digitarald>	oauth doesn't have both for example
Nov 18 16:36:19 <digitarald>	or logging in with remember-me token
Nov 18 16:38:23 <johanness>	why would you require a user provider if your filter doesn't need one?
Nov 18 16:38:31 <johanness>	besides you can always return empty strings
Nov 18 16:38:39 <digitarald>	I have authenticated users
Nov 18 16:39:05 <digitarald>	but I don't have passwords, they get authenticated against an API
Nov 18 16:39:17 <johanness>	then return ''; from the getpassword method
Nov 18 16:39:28 <johanness>	or throw an exception
Nov 18 16:39:42 <johanness>	latter is probably better
Nov 18 16:40:10 <digitarald>	I just don't understand the design decision
Nov 18 16:40:24 <johanness>	well the password is mandatory for some authentication providers
Nov 18 16:40:35 <digitarald>	most of the architecture is so flexible and thought through …
Nov 18 16:40:37 <johanness>	thus we need it on the interface, or we would have to create several interfaces
Nov 18 16:41:03 <digitarald>	than create a new interface
Nov 18 16:41:10 <johanness>	a password is not too uncommon when authentication is concerned
Nov 18 16:41:14 <digitarald>	same applies for applications where users login with facebook
Nov 18 16:41:21 <digitarald>	and that is *common*!
Nov 18 16:41:30 <johanness>	np the system can handle it
Nov 18 16:41:47 <digitarald>	yes, by not using the default user or misusing the interface
Nov 18 16:42:01 <digitarald>	why provide an interface when u have to hack it
Nov 18 16:42:09 <johanness>	you don't have to hack it
Nov 18 16:42:14 <johanness>	throwing an exception is no hack at all
Nov 18 16:42:31 <digitarald>	ok … common usecase: FB auth
Nov 18 16:42:43 <digitarald>	u get a session id and would log the user in with that
Nov 18 16:42:51 <digitarald>	user id and session
Nov 18 16:43:58 <johanness>	ok
Nov 18 16:44:14 <johanness>	i see no problem there
Nov 18 16:44:27 <digitarald>	what would be username … password?
Nov 18 16:44:48 <digitarald>	in the old authentcated user … I would have saved both in an attribute and set the user authenticated
Nov 18 16:45:08 <jmikola|w>	digitarald: I recall there being a mailing list discussion where username would be replaced with something more generic like uniqueIdentifier (this was the same discussion principalIdentifier - from Spring - was brought up, but most people didn't like that :)
Nov 18 16:45:17 <johanness>	you only need a user provider if you want to persist something
Nov 18 16:45:27 <johanness>	you can go ahead and store these details in the session if you like
Nov 18 16:45:34 <jmikola|w>	johanness: what if he's looking up users by their FB id though
Nov 18 16:45:42 <jmikola|w>	from the database
Nov 18 16:46:05 <johanness>	well username is whatever is a unique identifier for the user
Nov 18 16:46:25 <johanness>	i guess the user id would be best, but i havent build a fb app :)
Nov 18 16:46:25 <digitarald>	than its a really bad name
Nov 18 16:47:04 <digitarald>	"A username is a way of telling who is writing something."
Nov 18 16:47:13 <johanness>	yeah we had that discussion as jmikola|w pointed out, and i would prefer sth else too
Nov 18 16:47:32 <digitarald>	too much hardcoded magic in a *really* base class
Nov 18 16:47:53 <jmikola|w>	in the last two production apps i've developed, once we added third-party accounts (FB, twitter, etc.) the notion of a username/password disappeared
Nov 18 16:47:55 <digitarald>	I check if I can override UserProviderInterface
Nov 18 16:48:12 <digitarald>	remove the magic
Nov 18 16:48:21 <jmikola|w>	and it all came down to user id and some mechanism to resolve the authentication service's response into a user id (and thusly a db entity)
Nov 18 16:48:32 <digitarald>	wherever that piece is in the architecture
Nov 18 16:48:45 <digitarald>	but who needs db identities
Nov 18 16:49:03 <digitarald>	my app is driven by a java based API
Nov 18 16:49:20 <johanness>	as i said if you don't want to persist that, you dont need a user provider at all
Nov 18 16:49:21 <digitarald>	+ logins via oauth 3 like db and linkedin
Nov 18 16:49:35 <digitarald>	but I want to use the firewall
Nov 18 16:49:39 <johanness>	you can
Nov 18 16:49:48 <digitarald>	and fireall wants providers, as I see it from the docs
Nov 18 16:49:50 <johanness>	you need an authentication provider, and a firewall listener
Nov 18 16:49:55 <johanness>	thats all
Nov 18 16:50:04 <digitarald>	ok … is there any example app?
Nov 18 16:50:10 <johanness>	i guess not :)
Nov 18 16:51:30 <johanness>	right now there is also no easy way to get a listener into the firewall, so that would be quite some work to do
Nov 18 16:52:06 <digitarald>	…
Nov 18 16:52:57 <digitarald>	so its time to go to bed and go back to 1.4 … project is scheduled for April, thought 2.0 would be the way t go
Nov 18 16:53:22 <digitarald>	but I guess only if I stick to the magic that gets added
Nov 18 16:53:50 <johanness>	its actually highly configureable, only that not all options are properly exposed yet
Nov 18 16:54:16 <digitarald>	which makes it not so configurable …
Nov 18 16:54:32 <digitarald>	ok, cheers and thanks a lot for the advices
Nov 18 16:55:08 <digitarald>	I didn't leave the symfony2 party yet, gotta understand why its so hard
Nov 18 16:55:30 <digitarald>	and why a basic user can't be simply authenticated but needs a username and a password
Nov 18 16:56:02 <johanness>	i'd recommend to dive into the code base if you really want to understand it
Nov 18 16:56:57 <johanness>	its not as simple as 1.4 but it takes a lot of ground work away from you imo
Nov 18 16:57:34 <jmikola|w>	digitarald: now is the time to yield some influence with patches to the architecture :)
Nov 18 16:57:39 <jmikola|w>	since things are still up in the air
Nov 18 16:58:03 <jmikola|w>	hopefully we can get enough people with non-traditional user/password cases and make an argument for something very flexible
Nov 18 16:58:24 <jmikola|w>	this might make a good IRC meeting topic for the coming weeks
Nov 18 16:58:34 <johanness>	i think providing support for facebook out of the box might facilitate this
Nov 18 16:59:05 <lsmith>	well SSO via token's is definately a big topic these days