Open planflux opened 7 years ago
It's possible for users to remove all their (other) sessions. It's also valid for a limited time (although this is extended when used). A session isn't translatable to the user's actual password, so when it's expired or removed by the user it's useless. Does that make it "handled"? I think Superlogin has implemented this in common way, but I have to admit I've also had a hard time finding resources on this, especially when you don't have a background in this.
Yes, the use of the token is basic oauth. The implementation could be done a little better though, with a token that change and a refresh_token logic but the actual implementation is secure enough.
Also if you use ssl I don't see how the token and password could be stolen. I mean, login and password could be stolen too.
thank you @micky2be and @peteruithoven. I am still having a difficulty to access couchDB using the token:password. I am running into problems when using token/password pair to sync the pouchdb/couchDB. I am getting 500 error messages. It appears that I get those only if I sign in fresh from a browser with cache cleaned, meaning pouchdb will try to access the All_doc of user "smith"'s personal DB "sldemo_todos$smith". Since $smith is not an admin user, the couch server returns 500 error.
My code is as follows: ''' @Injectable() export class PouchDataProvider { db: any; data: any;
constructor() {
}
setRemoteDb(url){ this.db = new PouchDB('todos2');
let options = {
live: true,
retry: true
};
this.db.sync(url, options).on('error', console.log.bind(console));
}
The setRemoteDB is called when a user login is successful:
superlogin.login(credentials)
.then(res=> {
self.navCtrl.setRoot(TabsPage);
var remoteDbUrl = superlogin.getDbUrl('todos');
this.pouchdataService.setRemoteDb(remoteDbUrl);
console.log(remoteDbUrl);
//this remoteDbUrl looks like this: //'http://CoUzadUIQfeRJ_b5KSqaog:xtSzW_6sTBmosxxxKpeSKg@localhost:5984/sldemo_todos$smith'
}, function (err) {
self.authPending = false;
if(err) {
self.loginError = err.message;
} else {
self.loginError = 'Could not connect to the server.';
}
});
'''
How does superlogin deal with this type of security issues? I believe it has been handled, but I don't seen to find it described anywhere.