User with username and password auth

[lagom]

User with username and password auth

[lakhina]

@jroper Can you please guide on this.

[jroper]

Hi @lakhina,

I was more thinking of form based login with cookies. online-auction already uses cookie based authentication, so all that's needed is to provide a login page, where the user can enter their username and password, and that should submit it to a controller that checks that the password is correct, and if it is, set the current user in the session to be that user.

Currently we already have this:

https://github.com/lagom/online-auction-java/blob/master/web-gateway/app/controllers/Main.java#L65

That's how login currently works, you simply pass in the user id, and it logs you in as that user id, which is fine for using the drop down to log in as a particular user, and as mentioned we want to continue to support that for demo purposes (of course, in a real world app you would never support that). But we should add a new login action that takes a form that contains the username and password, the action will then send the login request to the user service, which will look up the user for that username, and then check that the password is correct. If it is, it will return a success, and the action can then set the current user in the session. If it isn't, the user can be sent back to the form with an appropriate error. Does that make sense?

[lakhina]

@jroper As per I can understand in this way we will we will not be authenticating each REST call we make to the server. Please correct me if I am wrong.

[ignasi35]

@lakhina we could if we add username/pwd on each call and create and setup new HeaderFilters for each service.

but that would be wrong. It is a bad idea to have a username/password pair in memory and send it on every request. Instead we should use some other form of authentication between services. But that is quite a big task.

This issue should only manage the authentication between the browser and the Play application. Once that is completed following @jroper's suggestion we can merge the PR and have a scenario where the perimeter application (play) is the only one requiring valid credentials and the internal communications (play-to-service or service-to-service) is considered trusted.

We can improve that later.

[lakhina]

@ignasi35 As we want both type of signin options available I will add username/password option in tool if server is started with particular additional parameter. Will that be fine?

[lakhina]

if that env var is set to true we provide login screen and hide dropdown and vice versa

[ignasi35]

Prefer a settings over an ENV_VAR. Also, I think it's best if we use a String settings instead of a Boolean. That will give as more freedom of movement when we want to implement other login alternatives: use-login="<[empty]|basic-form|OAUTH|fancy-stuff|other-fancy>"

[octonato]

I personally don't think we should support both methods. I doubt if someone will configure it differently just for the sake of not using a login form. The intention is to have a demo app.
(my 2 cents)

[ignasi35]

I personally don't think we should support both methods. I doubt if someone will configure it differently just for the sake of not using a login form. The intention is to have a demo app.(my 2 cents)

I've reconsidered. I agree to @renatocaval's statement.