[openstreetmap/openstreetmap-website] Use an authorisation framework (#1626)

[Andy Allan]

Our codebase currently has a home-grown permissions system. The logic of who can do what is built into every controller action, which is becoming unwieldy, particularly when we want to allow multiple types of user to do something (e.g. allow the user, moderators and admins to delete something). We also have a "default allow" system, where each action is permitted to all users, unless we add permissions checks. I'd like to make it easier to add more roles (e.g. like allowing people to moderate diaries without being able to block users). And as with much of what I work on here, I'd like to tack towards standard solutions.

So I'd like to move to a third-party authorisation framework. I'd like to see in particular:
* A default deny policy, so that actions aren't accidentally accessible.
* A centralised authorisation configuration, so that permissions aren't scattered all over the site.
* A system that's powerful enough that we can write complex authorisation rules.

I'm particularly fond of [decl_auth](https://github.com/stffn/declarative_authorization/) but unfortunately that is now unmaintained and none of the forks have gathered any momentum. The best alternative that I've found is [CanCanCan](https://github.com/CanCanCommunity/cancancan), which behaves similarly to decl_auth, but their Ability class looks a bit clunky compared to the decl_auth authorisation_rules DSL.

https://www.ruby-toolbox.com/categories/rails_authorization.html has a list of alternatives.

Because this will be a bit of an invasive surgery, I'd like to get other people's thoughts before jumping in at the deep end.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/1626
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20170830/1301a889/attachment-0001.html>