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
