I'm not sure if I've misread the question, but it looks to me as if the only complication here is that you are dealing with two different ways of forming a password for an account. In this case, and if it's the case that both ways of forming a password (null, and encoded with salt) apply to the same firewall, then I think it's just a matter of simply writing a chain password encoder (implementing Symfony\Component\Security\Core\Encoder\PasswordEncoderInterface) that takes password encoders representing these two things and checks against each in turn (you'd then declare this as a service and reference it as an encoder in your security configuration). I'm not sure, from reading it, that you'd need to write your own user provider - you should be able to use the FOSUserBundle one unless you know you definitely can't.
If you're using the form login provided by FOSUserBundle you may need to overwrite the validation on the data object for the form so the password field doesn't have a NotBlank constraint. I hope that makes sense/ is helpful! Douglas On Saturday, November 17, 2012 4:23:23 PM UTC, 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
