search

mx3 / mx

The Rails 3 fork of mx
http://mx-phenomix.org
6 stars 2 forks source link

Review user roles and login system #31

Open mjy opened 12 years ago

mjy commented 12 years ago

We might consider updating to a gem based authorization/roles project at this point. At present everything actually works except users can view/edit projs (the project record itself) they don't belong to.

I don't see a huge need to change, except perhaps to get some OPENIDesqe functionality integrated (login with my whatever account), and we might position ourselves to better define roles for future feature requests. Comments/thoughts welcome.

Quick overview of the required functionality, the setup is pretty basic:

A request either comes from a logged in user, or it doesn't. All those controllers in /api or /public do not require login, all other controllers require login.

In addition controllers 'admin', 'namespaces', 'image_views' can only be CRUD viewed by a person with is_admin = 1. Other methods internal to them must be accessible in some cases (e.g. autocomplete_for_image_views).

A logged in user can only view resources that belong to a proj that he/she is a member of. This is checked (presently) in the appliccation_controller by comparing the session[:person] to the users in @proj. @proj is currently set on every request (perhaps we could memcache it for a speedup?).

kcranston commented 12 years ago

It seems like we should have a few possible roles:

And then one or more user roles:

mjy commented 12 years ago

On Fri, Jan 13, 2012 at 1:57 PM, Karen Cranston reply@reply.github.com wrote:

It seems like we should have a few possible roles:

  • read-only (or, even better, the ability to make a project publicly readable without login): can browse, search and download but no changes

This is already very doable using the public/private setup.

  • admin (can create new projects, users, etc)

Think this is already doable too. New user creation is FOAF though, might want to restrict that somewhat.

And then one or more user roles:

  • user level 1: can code data, add new OTUs
  • user level 2: user level 1 + ability to add new matrices, new characters and character states These are only examples, might make sense to allocate allowable activities in a different way.

I think there are lots of possibilities. Comes down to exactly what you want to do.

https://github.com/ryanb/cancan + https://github.com/plataformatec/devise https://github.com/stffn/declarative_authorization https://github.com/zdennis/roles/wiki/Rails

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/31#issuecomment-3485245

caryfitzhugh commented 12 years ago

If we can keep actions on controllers matched with user's permissions - this sort of thing becomes trivial.

Those sorts of changes require nothing new in the auth system.

Having finer grained control can turn your app inside out and upside down with complexity.

But looking at the list above - seems you are pretty well set to fall into the first category. Only thing we'd need are a few before filters and some helpers to allow you to show / hide various links to allowed actions. I wouldn't go with muc more than that.

Matt - what are some of the challenges with public routes just not being the same as the normal route? (Out of curiosity?) On Jan 13, 2012 2:57 PM, "Karen Cranston" < reply@reply.github.com> wrote:

It seems like we should have a few possible roles:

  • read-only (or, even better, the ability to make a project publicly readable without login): can browse, search and download but no changes
  • admin (can create new projects, users, etc)

And then one or more user roles:

  • user level 1: can code data, add new OTUs
  • user level 2: user level 1 + ability to add new matrices, new characters and character states These are only examples, might make sense to allocate allowable activities in a different way.

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/31#issuecomment-3485245

mjy commented 12 years ago

Matt - what are some of the challenges with public routes just not being the same as the normal route?  (Out of curiosity?)

Not many really, is open to rethinking/simplification. 1) Login is never required. 2) Organizational- it was much easier to know that code in /public can never have "delete" etc. links, can be embedded within different layouts etc.

Tangentially related to routes- a project has to be loaded on each call but in some cases is detected from the base URL alone, e.g. portal.hymao.org maps to project 32.