Authorization

[mikaelsvensson]

The current API does not differentiate between different users but future administrative feature will require different users to have different privileges.

Implement some kind of role-based authorization mechanism.

Examples of actions which a user may be authorized to perform (values in parenthesis show how the action/permission may be stored in the database):

• Create new activities (activity.create).
• Edit or delete own activity (activity.edit.own).
• Edit or delete any activity (activity.edit).
• Create/edit activity without an editor having to review it before publishing it.
• Upload new media files, e.g. activity photos (upload.photo).
• Add comment to any activity (comment.create).
• Edit or delete own comment (comment.edit.own).
• Edit or delete any comment (comment.edit).
• Create/edit comment without an editor having to review it before publishing it.
• View system status (system.message.read).
• Add, edit or delete system configuration message, e.g. alerts about future down-time (system.message).
• Assign any role to any user account (auth.role.assign).
• Assign own role to any user account (auth.role.assign.own).
• Edit or delete any user account (auth.user.edit).
• Edit or delete your own user account (auth.user.edit.own).
• Create new category (a.k.a. tag) in existing category group (category.create.existinggroup)
• Create new category group (category.create)

User's must also be able to authenticate themselves using passwords.

[mikaelsvensson]

How to store passwords securely: http://throwingfire.com/storing-passwords-securely/ https://crackstation.net/hashing-security.htm

[mikaelsvensson]

How to provide role-based authorization: http://railsapps.github.io/rails-authorization.html https://lostechies.com/derickbailey/2011/05/24/dont-do-role-based-authorization-checks-do-activity-based-checks/ http://railscasts.com/episodes/188-declarative-authorization?view=asciicast https://github.com/elabs/pundit https://hackhands.com/ruby-on-enums-queries-and-rails-4-1/

[TheSwedishScout]

som, jag ser det så är det 3 eller 4 användar nivåer där jag skulle säga user, mod och admin och den jobbigaste anonym. kan vara en mellan mod och admin med. där jag skulle sortera följande: anonym : (käns som att man skulle kunna skipa denna men om den är med så skulle komentaren behövas godkännas.) Add comment to any activity (comment.create).

User: same as anonym Create new activities (activity.create). Edit or delete own activity (activity.edit.own). Edit or delete own comment (comment.edit.own). Edit or delete your own user account (auth.user.edit.own). Upload new media files, e.g. activity photos (upload.photo). on own activity!

mod: same as User Edit or delete any activity (activity.edit). Create/edit activity without an editor having to review it before publishing it. Edit or delete any comment (comment.edit). Create/edit comment without an editor having to review it before publishing it. Create new category (a.k.a. tag) in existing category group (category.create.existinggroup) Create new category group (category.create) Upload new media files, e.g. activity photos (upload.photo). Assign own role to any user account (auth.role.assign.own).

admin: View system status (system.message.read). Add, edit or delete system configuration message, e.g. alerts about future down-time (system.message). Assign any role to any user account (auth.role.assign). Edit or delete any user account (auth.user.edit). (all)

[mrManner]

It's not exactly a role - but as a future update maybe some kind of access control list for each activity, where there's one owner per activity, who can then add collaborators who get edit privileges? That might include the need for a activity.edit.acl permission here, so that one can block editing entirely on a per user-basis as well.

[mikaelsvensson]

Vi verkar vara överens om att detta:

• Exakt en roll per användare
• Upp till fyra olika roller i systemet
• Roller har olika nivåer och en roll ärver alla rättigheter från roller med lägre nivåer. Exempel: rollen Administratör har en högre nivå än Redaktör och får därför göra allt om Redaktör får göra, och lite till.

Tekniskt kan man ge varje roll ett heltal (nivån) och sedan koppla en rättighet, såsom att redigera aktiviteter, till en viss nivå (och därmed de roller som har den nivån eller en högre nivå).

[mikaelsvensson]

Nu finns den rollbaserade behörighetskontrollen implementerad i API:et. Förhoppningsvis finns det inga buggar, ex. operationer som borde skyddas av behörighetskontroller men som i praktiken inte skyddas, men tyvärr är ju snabbt skriven kod sällan buggfri.

Dokumentation av behörighetssystemet: roles-and-permissions

I princip så blev det som vi skrev här i ärendet: En roll per användare, initialt fyra roller i systemet, varje roll ärver rättigheter från rollen under i hierarkin.

Nya funktioner i API:et för att hantera användare och rättigheter:

• show-all-roles-and-permissions för administrativa klienter
• assign-role och update-user
• show-current-users-profile inkluderar nu en lista med alla användarens rättigheter
• search-for-users
• display-single-user