The pure CSS loading icon uses an ::after pseudo-element, and thus it
can only be used on container elements; the input element is not a
container element, so when the class "icon-loading-small" is set on an
input element it falls back to a loading icon GIF.
This commit modifies the markup of the login button to add a div element
that holds the confirm icon and the loading icon (depending on the
case). In order to position the icon in the same place as before the
input and the icon are both wrapped by another div making possible to
set the absolute position of the icon relative to the input.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Nextcloud is not properly loaded in the standalone version (especially the theming)
* it is already not listed anymore in the Nginx config (see nextcloud/documentation#392)
* the index.php-free version doesn't support this
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Use Unified function to emit <link> tags for css loading, obey "Don't Repeat Yourself" ;-)
(Next step might by to combine this with the emit <script> function (even more DRY?) AND move all this to a better place?)
Signed-off-by: Michael Letzgus <michaelletzgus@users.noreply.github.com>
* Create generalized function for emmitting <script defer src=""> tags to templates
* Remove type attribute from inline_js
* Add defer attribute to external <script> tags
Signed-off-by: Michael Letzgus <michaelletzgus@users.noreply.github.com>
* adds a disclaimer that an update via web UI is on own risk
* allows to skip the warning
* fixes#4353
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
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>
* currently there are two ways to access default values:
OCP\Defaults or OC_Defaults (which is extended by
OCA\Theming\ThemingDefaults)
* our code used a mixture of both of them, which made
it hard to work on theme values
* this extended the public interface with the missing
methods and uses them everywhere to only rely on the
public interface
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Morris Jobke
Jan-Christoph Borchardt
Daniel Calviño Sánchez
Joas Schilling
Marin Treselj
Maxence Lange
Michael Letzgus
Bjoern Schiessle
Lukas Reschke
Robin Appelman
Christoph Wurst
Roeland Jago Douma
Julius Härtl
Pierre Rudloff