summaryrefslogtreecommitdiffstats
path: root/core/js/login
Commit message (Collapse)AuthorAgeFilesLines
* fix(grant): remove JS error on Grant pageMagnus Anderssen2023-10-261-1/+1
| | | | | | Closes #41098 Signed-off-by: Magnus Anderssen <magnus@magooweb.com>
* Fix event listener race condition on login-formMarcel Müller2023-01-231-0/+2
| | | | Signed-off-by: Marcel Müller <marcel-mueller@gmx.de>
* Fix login flowCarl Schwan2022-07-271-1/+6
| | | | Signed-off-by: Carl Schwan <carl@carlschwan.eu>
* Add button disable on submit for login grantLukas Döllerer2022-07-251-0/+1
| | | | Signed-off-by: Lukas Döllerer <info@lukas-doellerer.de>
* The loading animation is backDaniel Kesselberg2019-10-261-8/+9
| | | | | | | | Refactor grant.js to Vanilla JS Remove id="submit" because of side effects: https://stackoverflow.com/questions/22982741/form-submit-jquery-does-not-work Fix arrow for login flow v1 Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
* Fix loginflow with apptoken enter on iOSRoeland Jago Douma2019-01-041-8/+0
| | | | | | | It seems iOS doesn't like us to change the location. So now we submit it to the server that geneartes the redirect. Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Remove redirect pageJohn Molakvoæ (skjnldsv)2018-11-292-3/+9
| | | | Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
* Update login flow redirectionMario Danic2017-05-041-3/+4
| | | | Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
* Fix some long lines in JS - JSLinut recommendationMorris Jobke2017-05-011-1/+3
| | | | Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Add new auth flowLukas Reschke2017-04-252-0/+16
This implements the basics for the new app-password based authentication flow for our clients. The current implementation tries to keep it as simple as possible and works the following way: 1. Unauthenticated client opens `/index.php/login/flow` 2. User will be asked whether they want to grant access to the client 3. If accepted the user has the chance to do so using existing App Token or automatically generate an app password. If the user chooses to use an existing app token then that one will simply be redirected to the `nc://` protocol handler. While we can improve on that in the future, I think keeping this smaller at the moment has its advantages. Also, in the near future we have to think about an automatic migration endpoint so there's that anyways :-) If the user chooses to use the regular login the following happens: 1. A session state token is written to the session 2. User is redirected to the login page 3. If successfully authenticated they will be redirected to a page redirecting to the POST controller 4. The POST controller will check if the CSRF token as well as the state token is correct, if yes the user will be redirected to the `nc://` protocol handler. This approach is quite simple but also allows to be extended in the future. One could for example allow external websites to consume this authentication endpoint as well. Signed-off-by: Lukas Reschke <lukas@statuscode.ch>