Implement authentication, access rights and user settings

[superpowers]

Implement authentication, access rights and user settings

[rhin0cer0s]

We can't protect users from malicious server owners storing a user's password

Like any other web service. The other problem would be "how to know that a server is really the one it annonces ?" and the best solution today remains PKI based even if it is far from enough. Anyway, this introduction is clearly acceptable.

We could use sqlite but it seems overkill

I agree. If you managed to avoid the use of a DBMS so far let's keep it that way.

The global server password will be re-purposed ...

Yep, a password just to access the server is definitely a great idea. I will be glad to offer a PR regarding the password storage and verification (as discuted in #52).

QUESTION: The primary key for the user account would then be its username. ...

I have absolutely no idea for this one. Fixing something is generaly not a good thing but here it doesn't seem really serious. If someone really wants to change its name why not just add a field "nickname" which can be modified freely ?

No access to anything (not even the list of projects)

? So no access to the server ?

This list makes me think : is there an activity log somewhere ?

[elisee]

Thanks for the feedback!

? So no access to the server ?

Ah right, I had something in mind but didn't explain it. The idea would be that the person was invited to sign up, and once they've done it, the server owner defines which project they can access after the fact. It's useful if you want to let a user join a single project and nothing else.

(... We might want to have a more elaborate invite link system that comes with predefined access rights for a particular project at some point.)

This list makes me think : is there an activity log somewhere ?

There is not. We might want to build one though, it seems useful. At the very list it could log connections, maybe high-level changes like project creation or even more detailed like asset tree changes, etc.

[Xstoudi]

QUESTION: The primary key for the user account would then be its username. Is that a bad thing? Do we care about renaming accounts on servers? If so, where will we reference user accounts in Superpowers? do we need to have a never-changing user ID instead?

I think primary key should never be a concret information. Create an unique user ID can prevent many problems.

[elisee]

@Xstoudi yeah alright, let's do that. It's probably for the best.

[elisee]

A much simpler version of this spec has been implemented:

• We now use passport-local for managing user sessions. The server password is no longer stored in a cookie for each user, which was a terrible temporary hack that stayed around for way too long.
• We're sticking to just a global server password for now, since it has proven good enough. We might do access rights some day, but for now it's not a priority for anyone AFAICT.
• Per-server user settings have been implemented using localStorage. It's good enough and much simpler than trying to synchronize them across all servers. We can improve on that later if needed.

So I think we can close this!