nextcloud

Tree: ad5093b7a6

Author	SHA1	Message	Date
Roeland Jago Douma	177c8972cc	Improve login flow * Add page explaining you are about to grant access * Show grant access page after login Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>	6 years ago
Julius Härtl	cd1bfea8c4	Theming: theme flow redirection page Signed-off-by: Julius Härtl <jus@bitgrid.net>	6 years ago
Roeland Jago Douma	f2d4c64c9a	Translate Grant Access Fixes #7038 Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>	6 years ago
Morris Jobke	44c6745159	Remove quotes around device name Signed-off-by: Morris Jobke <hey@morrisjobke.de>	6 years ago
Morris Jobke	bd43758118	Highlight client identifier in auth grant page Signed-off-by: Morris Jobke <hey@morrisjobke.de>	7 years ago
Jan-Christoph Borchardt	ebdfcb1fe3	Add heading to account access page Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>	7 years ago
Bjoern Schiessle	3775b14c4c	remove 'Alternative login using app token' in case of oauth login Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>	7 years ago
Lukas Reschke	5f71805c35	Add basic implementation for OAuth 2.0 Authorization Code Flow Signed-off-by: Lukas Reschke <lukas@statuscode.ch>	7 years ago
Jan-Christoph Borchardt	61af3f41f0	Fix auth flow background color and redirect view layout Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>	7 years ago
Roeland Jago Douma	05e1092c44	Correctly case the stateToken Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>	7 years ago
Lukas Reschke	6a16df7288	Add new auth flow 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>	7 years ago

11 Commits (ad5093b7a63d8b223c19953dc37cc33c31631be8)