search

bjornregnell / sigrid

Help queue web app for lab sessions and tutorials.
Apache License 2.0
10 stars 5 forks source link

Authentication #14

Closed elliotbrack closed 4 years ago

elliotbrack commented 4 years ago

Surely it's not such a great idea to have the password public in the readme? And surely it's a recipe for disaster to allow people to type in their own names?

I have a suggestion for a GDPR-compliant solution. A list of authorized supervisors is stored in some file. To log in, whether supervisor or student, you type in your username. You then have to read a file stored at some fixed path at login.student.lth.se ACL'd to you only. The file is generated by H(secret salt || current time rounded to hour || username), and validated by checking against the last N hours. The file could be updated by cronjob or whatever. Of note is that the scala code wouldn't need to touch the filesystem or anything.

The name is then extracted by assuming that the first name equals the given name and the name of address. That means no PII is ever stored, only first name as now, although validated.

The UX would be okay, since you could just put in a frame to file:// and ask users to copy-paste.

bjornregnell commented 4 years ago

Thanks for good idea! Will think about this and also make some trial hacks when time permits.

bjornregnell commented 4 years ago

It is not a problem that the scala code reads from local file on the server, as long as no user data is stored.

bjornregnell commented 4 years ago

@elliotbrack Another idea: Wouldn't a simple session id solve many of the issues? That is: generate upon login a session id as a random UUID java.util.UUID.randomUUID.toString store the id in the RAM keyValueStore together with the user name. In subsequent requests include the ?id=... and then it is not easy to just steal a user name and hack the URL.... This would avoid the crypto+salt complexity.

bjornregnell commented 4 years ago

I'm closing this in favour of: #14