Login Page and Passwords Storage

[shivenmian]

For #363, we decided on having an accounts system for the Provisioning process. The Sign Up page is made, the login page needs to be made. Also, the login page will have a password recovery system which connects to an email server and uses the class in #424. I will make the page and set up the server.

For the passwords we get from #357, we need to store that in a database which has an ACL (access control list), i.e not all people should get access to it. For a database we right now have elasticsearch but it does not have an ACL mechanism, so we need to figure out where to store them without them being publicly accessible.

@Orbiter views?

[Orbiter]

I am working on the storage right now. This is part of the AAA concept, see https://github.com/loklak/loklak_server/issues/363#issuecomment-220008513

[shivenmian]

I'm thinking of storing passwords on the elasticsearch db, so that I can make the login page and the password recovery email server. We can then remove the file and use your storage work once I'm done making the login and the password recovery. We can just test with a few test passwords and make both of them work, then use your storage work and make the passwords secret. Also, those passwords will need to be hashed as well.

I'll make the login page, use that temporary storage and try to set the recovery server for now @Orbiter

[rmader]

For the browser login (via login page that sets a cookie):

• it queries the local api as discussed in #357 that checks if the login credentials are valid
• it then sets a cookie which contains a hash of certain things only we and a valid user can know (like userid, hashed password as stored in our database, new random salt (which also has to be added to the database))
• depending on whether the user checked a "stay loged in" checkbox, set expire time to not more than a few hours or forever
• write this expire time to user account data
• on each request to the website, check for the cookie. If set, check the hash and expire time for validity, reset expire time in cookie and database
• If login in forever, refresh the hash with a new salt after longer periods (just a best practice)

[rmader]

@Orbiter do we have a structure for the authentication file already? Is it something like the following ok? Like objects with the userids (email adresses) as names? { userid : { password : "bla", salt : "112334534" }, userid2 : { password : "bla", salt : "112334534" } }

[rmader]

Ok I added a function getAuthenticationObject(request) to AbstractAPIHandler to verify logins: https://github.com/loklak/loklak_server/tree/loginVerification

We still need to discuss how exactly this files should be structured, but overall this funtion should do the following:

• if a request has user_id=something and password=somethingelse set, it will validate them (comparing it's hash to the one we store in the authentication file). This method can be used by scripts, but also for the login formular, which can just do a request to any servlet that implements AbstractAPIHandler, with user_id and password with the values from it's form.
• if request_session=true is set in the request, it will start a session. The login form should do that. For scripts we don't want to create sessions
• if request_cookie=true is set, it will create a long living cookie. That can be done if in the login form a checkbox "Stay logged in" is marked. The cookie is not ready yet, so it's ignored atm
• if a session is set, the user stays logged in (no further checks needed)

If the function validates a login, it returns a authentication object (can be changed to something else) or null otherwise

This function should be called on each request

tldr; script simply include user_id=something and password=somethingelse in their parameters login script does a post with user_id=something, password=somethingelse and request_session=true. That will create a session on succes, which is then enough to browse around, staying logged in. If logout=true is set, a session gets destroyed. Use this for a logout button.

[Orbiter]

@treba123 yes we have a structure for authentication. It requires a 'credential' which retrieves the authentication details from the authentication.json in settings, see https://github.com/loklak/loklak_server/blob/master/src/org/loklak/server/AbstractAPIHandler.java#L115-L126

You would need to implement a 'Credential' class (very similar to the 'Identity' class) which has a key that can be used to retrieve the credential information using a key format, starting with a credential name, followed with a colon ':' and the credential user input. Like "WWW-Authenticate"+ ":" + challenge. Or "Cookie-type" + ":" + cookie-content.

[rmader]

Ok, will adjust my code to return a credential. Or, to make things more clean, just an identity authentication.

@Orbiter I'm not really seeing the structure where you're heading yet. The function I wrote already contains code to check logins via session (and long living cookies can be added easily) and parameters, all things that are easiest to do from the request. But I don't see in which class it should go in the end. Do we really need Authentication on top of Identity and so on? Can't we just do the checks in one place, creating a Identity?

What's the benefit of having a Authentication and Credentials class if they're only used once to create an identity from it?

I don't want to say it's a bad approach, but if we know better how you want to do something we can help you much better. Especially to debate what's the best way to implement something.

Edit: just saw that you wrote me, sorry. But i could also think to have that all combined in the identity, like Identity identity = new Identity(request); so we handle that in one place and just care what kind of indentity we've got. I'll try to write something like that and let you see it

[rmader]

Just to make clear why i'm so confused, here what I think I need to do:

• I need a request as input to be able to handle different kinds of logins
• A database where I can lookup user data and save some information (authentication.json)
• as I want to capsulate the different login methods, i'd like to return just one object which can the be used for authorization and accounting. The encapsulation makes sure we can add or remove login methods as needed without having to touch the other parts.

If i get it right, we want to use Identity for the authorization and accounting. Is it ok then that I just create the Identity right from the request?

[Orbiter]

No. an identity is something like an email address or a twitter account name. That is not what you get when a user logs in. What you get there is a cookie or a base64 from http-authentify. We must translate this into the identity, thats what the authentication database is used for.

[rmader]

Ok so i just return Authentication

[Orbiter]

Ah maybe you believe the translation credential -> authentication -> authorization can be done in one step because there is a 1:1 relation from credential to authorization: that is not the case. I am thinking of:

• every anonymous request has a credential, an authentication but a common authorization
• there might be several credential types for a single account (like user log-in and referer to woocommerce)
• there should be an administration options for authorizations which do not touch the credential type; therefore there must be an index on identities. Which we would not have if we store by credential.

[rmader]

Alright, I'm slowly getting what you mean. So Credetial just holds some kind of login data? And the Authentication object checks whether they are valid? Or does Credential already check? Or is the check done in AbstractAPIHandler?

My main question is were the difference between credential an authentication lies. Authorizarisation is clearly something else. Because in the end, we just need one place to validate them. We can of course first retrieve them in credential, save them and then check them in Authentication. Is that for some technical reason or just code style?

[rmader]

@Orbiter Just to explain again why I'm struggling with this Credentials class:

• To get the credentials I need direct access to the query
• depending on the login method, I still need control over the query after verifying the user (for example cookie login)
• I don't want to split the code for managing the login into different parts.

I'll therefor first go with this encapsulated approach and we can chage it later if we come up with a cleaner solution.

Edit: I created a credentials class as you said know and somehow see the point about it. But the login process for users is a bit complicated, therefor i will encapsulte only that.

[rmader]

Ok, if i get it right we now have an app that can be used to put sign in data and we have verifications of logins. What is missing now (if i get it right) is:

• a signup servlet, which takes the data from the app and decides what to do with it (write the data to database, return if that id is already taken etc.)
• a login servlet is not really needed as login is implemented in AbstractAPIHandler
• a login app, which sends login data to some servlet that implement AbstractAPIHandler

I'll write a simple sign up servlet now.

[shivenmian]

@treba123 Login app has been made in #443. I am going to add the Forgot Password option to it, other than that the design has been made.

[rmader]

Ok, we have a dummy sign up working now (see https://github.com/loklak/loklak_server/pull/485 and what @shivenmian will push), but the structure of the authentication and and of the database maybe needs to be changed a bit. Will do a bigger push for that tomorrow, need some time for that.

[rmader]

After reading a bit about login functionallity (for example this), I came to the idea that it would probably be usefull to make the AAA databases even more abstract. Like the following:

• we have one file for each A (authentication, authorization, accounting) each, which are connected via a unique ID
• this ID should probably not be an email, as we in some cases might not get any email (maybe woocommerce or some other kind of login)
• we have one database "accounts" where we have account specific data (also using the internal ID)
• email is just stored in the authentication db as login name and maybe in the accounts db as one field. They should be independent from each other, as a user might want to change his email (where she gets emails send to) but not nessecarily the login

Edit: ok, the ID is what the Identity object is supposed to represent if i get it right

[Orbiter]

This issue has already 17 comments, please don't increase complexity further. Make it simple.

[rmader]

Ok, most stuff is done now. Signup works, login just needs some little changes (@shivenmian is on it) so just the current status:

• you can signup and login via the apps
• you can also get access to every sevlet extending AbstractAPIHandler by adding login=... and password=(pw in base64). Furthermore you can add request_session=true to get a session (thats what the login app does, but we can also use it for links in woocommerce) and request_cookie=true to get a long living cookie (not finished yet, https://github.com/loklak/loklak_server/issues/497)
• you can see you current identity at api/logintest.json. normally that returns host:yourip, but if you are logged in (or supply login parameters) it will give you an email:something

The structure might not be perfect yet, but it should do for the moment. See: https://github.com/loklak/loklak_server/pull/496 https://github.com/loklak/loklak_server/pull/495 https://github.com/loklak/loklak_server/pull/494 https://github.com/loklak/loklak_server/pull/490 https://github.com/loklak/loklak_server/pull/487

The cool stuff about the parameter login is, that a script does need to support http_auth while the functionality stays the same and is alot simpler to handle in the code It is even used for the login without any overhead (the login servlet contains no login code, it only gives feedback. The actuall login can be done in every servlet aslong as AbstractAPIHandler is extended)

[shivenmian]

@Orbiter The signup is done, we have encoded the passwords and stored them. Will start on the login system now. I will also implement the Password Recovery server along with the login system after doing the JavaScript part.

[rmader]

As soon as the login app works, i'd suggest to close this issue and open new ones for details

[rmader]

Signup is now disabled by default in the config, just to not have any bots spamming us.

[shivenmian]

@treba123 The login page works fine, so I guess we can close this. Should we?

[rmader]

Yep, nice one.