Fauxton: Create fx roles

[garrensmith]

Fauxton auth works by checking what roles a user has and then decide if
they have access to a specific route. The only problem is a regular user
might get created but not have any roles. Unlike an admin user who get
assigned all the roles on creation.

The idea behind this is that certain routes should require a user to be
logged in but not necessary have any roles eg. #changePassword route.

This allows for a standard fauxton role that all logged in users get given so that
we can check via the roles if they are logged

[kxepal]

How about just _fauxton ?

[garrensmith]

I would prefer to prefix it so we can add other roles later if need be.

[kxepal]

I'd wouldn't be so optimistic since this mostly looks like a hack. But anyway, leading _ guarantees that no admin will create collision with your role to grant some actions on fauxton to specific users - CouchDB will not allow that, and _fauxton by itself is good prefix too.

[kxepal]

Also, am I right that you'd only fixed access to "Change Password" page? Because access to databases/replication still asks to log in (even if you're).

[garrensmith]

Correct I haven’t added it to databases and replication yet. I can do that. I first wanted to get some opinions on this approach. Its not the prettiest approach but I don’t want to spend too much time on auth until the Big Couch merge is over. So this should be “good enough” for now.

On 18 Jun 2014, at 4:44 PM, Alexander Shorin notifications@github.com wrote:

Also, am I right that you'd only fixed access to "Change Password" page? Because access to databases/replication still asks to log in (even if you're).

—
Reply to this email directly or view it on GitHub.

[kxepal]

Errhm..I just read the auth/resources.js code and found there nice function isLoggedIn - why not to use it instead of fake role to control access to "Change Password" page? Actually, access to that page is only reasonable when user is not anonymous e.g. has userCtx.name non null.

[garrensmith]

The isLoggedIn can work but the problem is we need to define via the auth roles in a RouteObject that this route needs to the user to be logged in. The only way to do that is via the roles.

[robertkowalski]

Will auth change with the BigCouch merge?

[kxepal]

@robertkowalski not auth, but set of default roles I believe. The code caused the issue was ported from Cloudant fork and it forces check user for some special roles.

[robertkowalski]

I think I am okay with it, I also have no better idea just now for a quick fix.

[garrensmith]

Great thanks. Merged.