UI improvement, Register button in Login page (and vice versa), Go back to the source page (client)
kerkmann opened this issue · comments
Right now there is a encapsulated Register Screen and a encapsulated Login Screen, but both of them are not really "connected together", they are more or less standing on their own. For example, a User is getting redirected to the login screen of Rauthy, then remembers that he doesn't have an account, then he has no chance to create a new account. A small register button besides the login button would be awesome.
A second thing is, the user is more or less "stuck" on the login/register screen, if a user is on the login page and would like to cancel the transaction, he's completely stuck. There is no "go back" button, which would redirect the user to the source application. Of course he could use the "back function" of his browser, but the redirects are making it impossible and it's not really user friendly. ^^"
PS: I would like to help out and create a PR. The frontend and backend is running, but I have no idea how I can get test data into it. There is no rauthy client creation, no admin account, and I am a little bit stuck there. Would be awesome if someone could help me out, so I could create a PR. ❤️ Thanks!
Right now there is a encapsulated Register Screen and a encapsulated Login Screen, but both of them are not really "connected together", they are more or less standing on their own. For example, a User is getting redirected to the login screen of Rauthy, then remembers that he doesn't have an account, then he has no chance to create a new account. A small register button besides the login button would be awesome.
You are right, there is absolutely room for improvement.
The register button below the login form would be a nice addon. But this must only be shown if OPEN_USER_REG == true in the rauthy.cfg. On the root page, this is checked / injected in a hidden input (which should be migrated to templates at some point, which would be prettier).
A second thing is, the user is more or less "stuck" on the login/register screen, if a user is on the login page and would like to cancel the transaction, he's completely stuck. There is no "go back" button, which would redirect the user to the source application. Of course he could use the "back function" of his browser, but the redirects are making it impossible and it's not really user friendly. ^^"
A back button is not too easy.
Pressing redirect in your browser could work, but that depends on the implementation of the other side, if the redirect has been done manually by javascript, or by HTTP 301 / 302 + location header. On the other hand, it is not trivial to show a "back" button on the Rauthy login screen, because we cannot know for sure reliably, where the user was coming from.
If the redirect_uri has been validated by the backend, we could use this of course, but this would not be the expected outcome of such a button and this page would probably throw errors, because we would not be redirecting back with valid params.
We could add a back button if we would allow configuring something like a "base url" for each client beforehand. Then the user would not get redirected to the exact page where he was coming from, but at least to the application root itself. This would need to be checked as well, because this value might not exist, but that is not such a big problem.
I am pushing new DB migrations with the next release anyway. I could add a migration to the clients table where we could save something like "base url" for a future back button functionality. I wanted to have another field for a contact for each client anyway.
Another thing I wanted to do anyway is to rename the button labels on the root page and remove the Login from them, because I found out that this often confuses people, when they actually are logged in already. So just name them Admin, Account, ... . And, if the user has an active session, a dedicated Logout button there would be very helpful, since this had some friction in the past as well. People just don't know, that for logging out, they need to go to their Account and then press Logout.
PS: I would like to help out and create a PR. The frontend and backend is running, but I have no idea how I can get test data into it. There is no rauthy client creation, no admin account, and I am a little bit stuck there. Would be awesome if someone could help me out, so I could create a PR. ❤️ Thanks!
Yes the CONTRIBUTING.md could be improved for new people. The default config on the master branch starts in DEV_MODE which is set in rauthy.cfg. In This mode, static data is being reused and inserted into the DB for dev and testing, instead of generating new credentials each time. This means even after a full database purge, we get the exact same data in dev mode to make life a lot easier.
The default admin is always
admin@localhost.de
with the default password
123SuperSafe
Additionally, depending on your environment, you want to adjust in the server section:
LISTEN_PORT_HTTPLISTEN_PORT_HTTPSLISTEN_SCHEMEPUB_URL(the most important here)
The PUB_URL really depends on where you have everything running. For instance I often use a dedicated machine in my network for running everything instead of localhost.
If you want to test things where you actually need "real" secrets for, I highly suggest that you just out-comment the variable in rauthy.cfg and create a /.env file. This is in the .gitignore, so you can add sensitive data there without worrying about accidentally pushing into git.
It is really hard to document this stuff for newcomers to the project and think about everything, when it all is 2nd nature to you. So if you have done setup, it would be really nice if you could add the additional things to the CONTRIBUTING.md in a PR.
I hope that helps a bit. If not, please let me know as well. :)
I just updated the rauthy.cfg to a better default version for new devs.
The PUB_URL is out-commented by default now and everyone should just set their preference in an additional .env file, where you could place other secrets and customs as well. This way, the default cfg will not be changed all the time with a new PR only because someone adopts to their own setup.
A dedicated section in the contributing readme will be a good idea for sure.
Pressing redirect in your browser could work, but that depends on the implementation of the other side, if the redirect has been done manually by javascript, or by HTTP 301 / 302 + location header. On the other hand, it is not trivial to show a "back" button on the Rauthy login screen, because we cannot know for sure reliably, where the user was coming from.
Yes that's true. A redirect wouldn't be the best solution.
We could add a back button if we would allow configuring something like a "base url" for each client beforehand. Then the user would not get redirected to the exact page where he was coming from, but at least to the application root itself. This would need to be checked as well, because this value might not exist, but that is not such a big problem.
We could use something like that, or we add a specific back_url in the database. Or another solution would be adding the ability for the client to add that query parameter to the uri and pass it through. This should be validated with the valid redirect uris.
Another thing I wanted to do anyway is to rename the button labels on the root page and remove the Login from them, because I found out that this often confuses people, when they actually are logged in already. So just name them Admin, Account, ... . And, if the user has an active session, a dedicated Logout button there would be very helpful, since this had some friction in the past as well. People just don't know, that for logging out, they need to go to their Account and then press Logout.
Would be awesome! One question regarding the logout, is there are post logout session endpoint, which destroys the session, is logging out the user and redirects them to a specific post_redirect_uri? Keycloak has something like that, this adds the ability for frontend clients to logout easily and redirects the user back to the frontend application.
I hope that helps a bit. If not, please let me know as well. :)
I just updated the rauthy.cfg to a better default version for new devs.
The PUB_URL is out-commented by default now and everyone should just set their preference in an additional .env file, where you could place other secrets and customs as well. This way, the default cfg will not be changed all the time with a new PR only because someone adopts to their own setup.
Thank you very much! you are awesome!
Yes that's true. A redirect wouldn't be the best solution.
I will add contact and application_url to the clients table tomorrow. These can be used to display contact information for a given client and we could add a link on the login page to the root URL.
Modifying the redirect_uri would not work, because this must be a unique param and this is used for the OIDC callback already.
Would be awesome! One question regarding the logout, is there are post logout session endpoint, which destroys the session, is logging out the user and redirects them to a specific post_redirect_uri? Keycloak has something like that, this adds the ability for frontend clients to logout easily and redirects the user back to the frontend application.
Yes, full support for that. When you click Logout from within your account view, you get to this page. It does accept id_token_hint as well and everything "should" work there already, even though there are no detailed integration tests for this feature yet.
This logout page will invalidate all tokens, delete session cookies and sets the expiry of the session to "now".
Edit:
You can send a post_logout_uri to the logout page as well, so the user will be redirected automatically. This will be validated against the allowed post logout uris configured for each client in the Admin UI.
So... #312 added support to save client_uri and contacts for each client. This means these can be added to the login page in the future, if they actually exist for the given client. Regarding the naming, I took the exact same names as the OIDC dynamic client registration RFC specifies them. This means, that these values should already be working with dynamic and ephemeral clients as well.
The PR did quite a few other things as well, but this is not related to this issue.
I did loosen up the specification for contacts quite a bit. By RFC, only emails are allowed here, but I changed it to make phone numbers and things like a matrix ID valid as well. I think this is more valuable to users.
I updated the integration tests for dynamic client registration and can confirm, that the new values work for dynamic clients as well.