New authentication service for semantic.works written in javascript #1
Conversation
- added some comments - replace res.status().send() to res.sendStatus where no msg is needed - add missing semi-colons -only use 1 try.catch block in each function
|
This is cool! The PR currently writes the accounts information to a single graph. In may settings, this graph would be determined by the some information related to the user (most often their uuid, but it could also be a related organization, the id of their account, ...). Perhaps we should create an async function to yield the graph? Perhaps some sensible defaults can be supplied through configuration. Cfr the hashing: I see a configurable salt, which is good. This ensures a generic rainbow-table cannot be used. I would add a per-password unique string (stored int he database) as an extra bit of random data to the password. This would ensure a rainbow-table couldn't be constructed against the whole database. |
|
Thinking about this further, the data will likely need to be split across multiple graphs. Some of this could be handled by mu-authorization but there is a bit of a chicken-and-egg problem in that mu-authorization doesn't know what data will be present before trying to insert that exact data. Either we should allow specific triples to be written to specific graphs, or we should execute some tricks to inform mu-authorization ahead-of-time. Tricking mu-authorization would involve removing the mu-auth-allowed-groups, storing the login information into a temporary graph using mu-auth-sudo, and then sending the data to mu-authorization again without mu-auth-allowed-groups. At that point mu-authorizition can use the temporary graph to figure out who the user is. Once that's done, we can remove the specific data we added to the temporary graph. It needs further thought (and perhaps experimentation?) to figure out the most sensible approach. I've enjoyed playing with this service. It's like a tasty 🍪 and I'm looking forward to gradually improve the recipe even further. |
This is probably more like a personal preference, I like it more since I find that try/catch blocks add noise, the use function in app.js takes care of catching errors instead
New authentication service, merging the functionality of the existing login-service & registration-service. Not to reinvent the wheel but rather to be a clone but instead written in javascript. Some small stuff is different though like using 'email' instead of 'nickname' but queries are almost a one-one copy.
Readme should clarify a lot.
Some comments