Hi Omega, Sorry to hear that you're frustrated! It can be a bit confusing to understand what's going on with the security component. I'll admit that I don't know all there is to know, but the below is based on what I've discovered as I've fumbled along.
I'll start with the token & then work up to the systems that you'll need to build to interact with it. The token is basically a data store for whether a user is authenticated. So, in your case, the only special info you need is to add a property to store the source of the user. I would recommend extending the UsernamePasswordToken to add the extra property, then use your class in your provider. The provider is where you get your user based on the details provided by the input (ie. username). The provider takes the data provided from the user, and validates it as required. The DAO Provider looks the user up in the database, and then authenticates the provided password against the one stored in the database. You can modify this behaviour to suit your requirements. There's the Authenticate method, which calls a checkPreAuth & checkPostAuth method, as well as the checkAuthentication method to authenticate the user. All of those can be modified to suit your logic. I'm sure there are others out there that have more experience in customizing the security stuff. Maybe Fabien can comment? Good luck! Cameron On Sunday, November 18, 2012 5:23:23 AM UTC+13, Omega wrote: > > I reluctantly post to this list as a last ditch effort to get help with > properly implementing my authentication requirements in a Symfony 2 project. > If I can't get a concrete response on the matter, I'm left with no choice > but to abandon all expectations of SF2 by way of the amount of time I've > wasted trying to figure out even a proper approach to this problem. I've > posted to various sources and tried to raise awareness over the issue, but > I think there's one particularly inconvenient truth: The default works for > 90% of the situations out there. > > So I'm left hanging now with my somewhere-in-that-ten-percent scenario. > When I ask for help, nobody responds because the stock of collective > understanding of this subsystem is so sparse that who in their right mind > would subject themselves to this. Which I think is telltale and needs to > be considered seriously. You can turn up searches on google that are > almost direct copies of the Symfony 2.x documentation, again telltale > considering that none of them make use of an entity manager! Of course the > real data on this will never be available, but it seems like the extension > of this aspect of the framework has been minimal in the wild. > > What I need to do: > > o I need users that have null passwords to be able to log in without a > password (user provider?). > o Users with a password need to be authenticated normally with their > password & salt (user provider?). > o Both types of logins need to store the id of the particular system > they've logged into (token?). > o I'm using form login and would like to rewrite as little as possible > (???). > > I think if it was solely a matter of writing my own user provider and > token, with a bit of guidance this would have been open and shut! > But...Create your own token and who is going to handle it? Create your > own user provider and who is going to call it? Let's not forget that all > of this has to go into the session, which the Symfony 2 documentation > kindly reminds us about with "AbstractAuthenticationListener" but says > little else. Surprise, there's an unimplemented method and holy smokes > look at that constructor, where am I going to find all of that?! > This is the point where everything gets hairy because now I'm implementing > the whole 9 yards with no guidance. If I try and extend the Dao classes a > whole new series of problems are introduced and I find myself slowly > working towards rewriting everything anyway and the documentation examples > are just too minimalist to be of any help. > > From my point of view, due to how highly coupled all of these classes are, > you might as well just roll them all into one uber authentication interface > and spare developers the dizzying toil of figuring out what has to happen > next and how to ease it all into place properly. It becomes a balancing > act I probably should have stopped stubbornly trying to follow the 2nd day > in and am now beating myself up over. > > The long and short of it is that I feel like making my painfully simple > situation happen in Symfony 2.x shouldn't feel like a gruelling exercise in > rewriting internals. Yes, customization of this layer makes use of the > dependency injection container but that doesn't make it self evident. The > workout you're forced to go through, the number of classes involved and the > inability to drop in replacement classes where needed without rewriting > everything around them completely defies the notion that this system is > extensible. > > I hope something can be done to improve this aspect of the framework and > make it more approachable for mere mortals such as myself. > -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
