You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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 :
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).
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.
The text was updated successfully, but these errors were encountered: