[Security] Complete overhaul of the security documentation #288
Conversation
…ders for connection information
…rkern/symfony-docs into thaberkern-cookbook_pdo_session_storage
[security] fixed wrong fully qualified class name in voter chapter.
Fixed typo in routing examples
…isionManager object.
…ymfony-docs into thaberkern-doctrine-repositories
[security] added a note to change the voter strategy in the AccessDecisio
Per comments from @stof, using the reference link collapses the class's name, which we don't want here since we want the reader to see the difference between the two potential base Command classes.
Conflicts: book/security/authorization.rst cookbook/map.rst.inc
Also adding more details about chapters to-be-written
| this login form visually is your job. First, create two routes: one that | ||
| will display the login form (i.e. ``/login``) and one that will handle the | ||
| login form submission (i.e. ``/login_check``): | ||
|
|
There was a problem hiding this comment.
You should not create a route for /login_check as it will never be used and can cause confusion to the user.
There was a problem hiding this comment.
I see now that you are using the login_check route in the templates. So, it is indeed useful... but confusing ;) As there is not controller, and because the /login_check is configured as a string directly into the firewall, why not use an hardcoded URL?
There was a problem hiding this comment.
I had the same thought. I can use a hardcoded URL, but what should that look like? Of course, the router also guarantees that I hit the same controller and stay under the right web root for my project.
Also, since the firewall effectively acts like a route+controller for /login_check, I instinctively want to ask the security system to generate the login check URL for me.
There was a problem hiding this comment.
I think the explanation you have for logout is perfect: https://github.com/symfony/symfony-docs/pull/288/files#L3R1376
There was a problem hiding this comment.
Good call, here's what I've done - I do think it's clearer, though I still make the user create both routes up front, because ultimately they'll "need" both: c4b0e78
|
Very well done @weaverryan! This is an excellent chapter about a very tough topic. |
|
Thanks! I've made the changes you've suggested - good catch on both of them. |
|
What about merging this soon? I think it's much better than the current doc. |
|
|
||
| If a user requests ``/admin/foo``, however, the process behaves differently. | ||
| This is because of the ``access_control`` configuration section that says | ||
| that any URL matching the regular expression pattern ``^admin`` (i.e. ``/admin`` |
|
I'm +1 about merging it. |
|
Thanks guys - last two changes made per @stof and this has now been merged in! |
Hi guys!
A long time coming, here is the refactored security documentation:
Also, one of the most important areas to attack - across the entire framework - is the configuration references. In the coming weeks, I'll try to organize people to attack that in a consistent way. Also, after this is merged, we should refactor the cookbook page - it's utterly unreadable now.
Comments warmly appreciated - thanks!