Jake Barnes says: "I created a test user account with no privileges. I log in as this test user. I point my brownser here: test_dev.php/sf_guard_user I now see listed all of the users, and I can edit any of them. So I open: plugins/sfGuardPlugin/modules/sfGuardAuth/config/security.yml And I add in: ..."
Three things: 1. Don't edit directly in a plugin folder unless you are the author. Your changes will get smooshed when you update the plugin. And you will update the plugin, because bugs and security holes are bound to be found over time in anything (not knocking sfGuard here, it's true for pretty much anything). Symfony provides for modules to be overridden at the application level. This is the correct way to change plugin behavior for your particular application. 2. Look at that URL: test_dev.php/sf_guard_user sf_guard_user, not sf_guard_auth. You're locking down the wrong module. There are several modules in sfGuardPlugin. sfGuardAuth is the one you DON'T want to secure, because it is the one that allows you to log in. You want to lock down sfGuardUser, sfGuardGroup, and sfGuardPermission. Do it here: apps/frontend/modules/sfGuardUser/config/security.yml apps/frontend/modules/sfGuardGroup/config/security.yml apps/frontend/modules/sfGuardPermission/config/security.yml These can be really simple, as you noted: default: is_secure: on credentials: admin Then symfony cc and you're good to go. 3. You might very reasonably ask why these modules are not secured by default. I'd like to know that too. As acceptance of Symfony grows, exploits for common holes like this will probably become common. I guess it might be a bit awkward to override if you wanted to set up security differently, but I'm pretty sure it's doable. In our own applications we never enable sfGuardUser, sfGuardGroup and sfGuardPermission. Since these are simple admin generator modules, we've copied them to pkToolkitPlugin, themed them and enabled security by default. For sfGuardGroup and sfGuardPermission we choose to require superadmin status, because the set of groups and permissions that are actually implemented in a project typically shouldn't be changed by our clients; these modules are used only in the event we make a design change. For sfGuardUser we remove the user-by-user setting of permissions, keeping only groups (guest, editor, admin) to simplify things for client admins. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
