Johannes clued me in to ContextListener::refreshUser(), which appears to be what Lukas was referring to. This only functions if the token is not immutable, which it would have been fine had I not been using SwitchUserListener (the impersonation session it creates uses an immutable token).
So if ContextListener::refreshUser() is functioning, I think Doctrine developers can do without re-authenticating after an edited, provided that their UserProvider's loadUserByAccount() method does its query based on ID instead of username. This should be a trivial change for FOS UserBundle at least. On Wed, Jan 19, 2011 at 5:31 PM, Jeremy Mikola <[email protected]> wrote: > Our account form allows users to edit their usernames. Actually, it's the > email address, but because we also have them login with their email, if > effectively the username. > > One thing I've noticed for some time is that when editing a user, you want > to use the object from the database, and not the user object from your > session (e.g. in Security component's current token). Hypothetically, if > uniqueness validation fails after binding request data, and you redisplay > the form with its bad username... anything else on the page that tries to > reference the current security user (e.g. the Profiler toolbar) will be > pointing to the same object, that Form::bind() just tainted. Because > Security component likes to carry a serialized User object, which is > unmanaged by Doctrine, I'm safe if I fetch a freshly managed User from the > database for my account form. But I believe there was something in the > works that would refresh the serialized User object from the database on > each request. Lukas told me this already exists, but I don't see how it > could be functioning right now. If the User object in the security token > was a managed Doctrine object, both it and the result from a fresh DB query > would surely reference the same object (and my "solution" above wouldn't > have worked). Doctrine is very strict about ensuring only a single > reference exists unique entities/documents. > > But I digress. The real caveat is that after an account form is > successfully submitted, and a user changes their username, the token has to > be updated. I can't just call setUser() to update its user, since the token > is immutable. I could cheat and dive into the token's User object and > update the username myself. The other alternative, which the FOS UserBundle > does, is create a new authenticated token with my freshly-updated and > Doctrine-managed User object. > > And that's where SwitchUserListener comes in. Switching users depends on > creating its own UsernamePasswordToken with whatever User I want to > impersonate, and then that User gets a special SwitchUserRole that > encapsulates my original (admin) User object. If we utilize the "reset > token after updating username" behavior, we ruin the SwitchUserListener's > ability to "exit" out of an impersonation. I suppose one solution here is > to check for the SwitchUserRole and re-inject it if necessary? > > I realize AccountInterface does not dictate a field for a unique > identifier, and internally Security component does its account-loading by > username (a possibly change-able field for a fair number of projects). For > anyone working with Doctrine, an ID will be a required field - so ideally I > would expect an account's ID to be the preferred field for refreshing > token-contained User objects (assuming that feature does exist, as Lukas > said :). > > -- > > I just wanted to throw these topics out there for discussion, as I think it > relates to something most all developers are bound to experience at some > point while working with User objects. The SwitchUserListener business less > so, as that's admittedly an edge case for most. > > -- > jeremy mikola > -- 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
