Drupal Association members fund grants that make connections all over the world.
The new routing system doesn't have access control yet. It needs it. :-)
There's also a long-standing list of limitations and annoyances in the current access system. We may as well try to address at least some of those along the way.
Symfony Full Stack uses a separate Security component for controlling route access that is far too complex for us to integrate in Drupal 8. We're not going there right now.
After talking with other Symfonians and Drupalers, it appears the correct approach, at a high level, is to "add metadata to Routes" and then "add post-matching request listeners that can reject access if appropriate".
There's two general ways that could be done:
1) Let every ACL module tack on whatever it wants to route definitions and implement its own request listener. So for example, we'd add a $request->setDefault('permission', 'access site configuration') value, and then add a listener that checks for a permission key on $request->attributes (where the matcher would stick it) and if it's set, runs user_access() on it (or whatever user_access() turns into). Other access checking systems could add their own properties and listeners.
Benefit: Really simple to implement, quite extensible, no significant architecture needs to be added.
Drawback: Potentially slower if there are lots of access listeners firing. Results in a "default allow" model. (That could be good or bad.) Possibility for namespace collision.
2) Implement a single listener that checks a series of conditions based on the values inside a sub-element of defaults. That may include permission checks but also anything else. What we'd add to that array then is not "the permission to use" but "the component to use and call with supplied information". This is conceptually closer to what we have now with "access callback" and "access arguments" but more robust and multi-plexed. We would likely want to make this either use the "Boolean plugin" that EclipseGc has been talking about -- in which case you need to pass all checks -- or model it on hook_node_access() and allow access plugins to return Yes, No, or I Don't Care -- and then you need "at least one Yes, and no Nos" in order to pass. Potentially we'd reference to service objects in the DIC so that we can keep the access checks testable.
Benefits: More robust implementation. *May* be faster. May be easier to extend depending on the details.
Drawbacks: More work and complexity to implement. I don't know that Boolean plugins are ready.
3) Nobody expects the Spanish inquisition! Even if we do option 2, there's nothing stopping option 1 from happening. They are not mutually exclusive except in terms of confusion.
Commit the routing issue above, figure out which of the above we want, and then code it up.
User interface changes
For now none, but it will have an impact on the SCOTCH interface work. Although they've probably thought about it already.
postponed on this issue.
PASSED: [[SimpleTest]]: [MySQL] 48,751 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 48,699 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 48,589 pass(es), 165 fail(s), and 39 exception(s). View