Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easy management of user access to databases #51

Open
Shocoben opened this issue Apr 19, 2016 · 1 comment
Open

Easy management of user access to databases #51

Shocoben opened this issue Apr 19, 2016 · 1 comment

Comments

@Shocoben
Copy link

Shocoben commented Apr 19, 2016

Introduction :

Imagine that you create an App, and you want to only allow some users (Premium account) to access to the server to sync (like evernote).

Actually, you have to do it manualy, by calling superlogin.addUserDB and superlogin.removeUserDB by http requests (on another protocol).

It would be nice to only manage it like this :

The userDoc has an variable (array) of roles / access.
And in the config file, or when you make an addUserDB, you can specify the required access.

userDoc.access = ["basic", "premium"]; //The user's accesses
databases = {
        "basicDatabase" : {
               "requireUserAccess" : [] //Everybody can access it !         
        },
        "premiumDatabase":{
            "requireUserAccess" : ["premium"] //Only users with "premium" access can access it.
        }
}

Then, you only have to manage the user's accesses, and when the user log-in, the session.userDBs is refreshed and allow the front part to easily identify the allowed ones.

What this feature must not forget :

  • It's mainly handled in the configuration, but it should not forget the manuals superlogin.addUserDBs. When you call superlogin.addUserDBs, you may be able to specify an requiredUserAccess for that database, so it can also benefit of the automatic user access management

Technical Debates

1) Should the new "user access management" use userDoc.access or userDoc.role ?

For me, it should use a special access variable, because userDoc.role and userDoc.permissions are used for technical access to Cloudant and CouchDB ['_reader', '_writer', '_replicator'].

But I'm still questionning about the userDoc.role, for me it would be nice to use it, but what I saw in lib/dbauth/cloudant.js , it's transformed to permissions.

2) The process of management

Solution A)

Use a filter on the userDBs sent into the session. I've a sample of that solution in this commit.

Solution B)

At the start of the user's session creation, parse userDoc.personalDBs and compare it to the access difined in the config (and don't forget the ones addes by addUserDB).

While parsing and comparing :

Do the user has access to that database ?
 YES = Do you already have that database in userDoc.personalDBs ?
         YES = No action
         NO = superlogin.addUserDB(user, databaseName, ...)
 NO  = Do you have that database in userDoc.personalDBs ?
         YES = superlogin.removeUserDB(user, databaseName, ...)              
         NO  = No action

And even, to optimize and not always do a parsing, you can use a system of databaseSignature.

A) A superlogin config has a signature (like "abcdefg45")
B) A userDoc has a personalDBs signature
B) Before doing the parsing & comparing, the management system check the user's signature and config signature, and if it's the sames : the system know it doesn't need to re-do the checking.

I've tried something similar in this commit

3) When execute the proccess management ?

For me the best, it to do it on the user's session creation, so it's not a big bottlenek, it won't surcharge the server, parsing all the users, and the front can get the good session.userDBs.

I think this feature might be really useful, and make superlogin more easy to use.

@colinskow
Copy link
Owner

I like your idea and think this would be perfect to execute as a plugin for SuperLogin hosted as a separate NPM package. You should be able to do everything you want through the public API. You can use superlogin.onCreate to intercept the userDoc of a new user before it is saved.

If there is anything you need access to that is not currently public API, I would be happy to help you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants