This can be used by pages that do not have the full Nextcloud UI.
So notifications etc do not load there.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When a password is reste we should make sure that all users are properly
logged in. Pending states should be cleared. For example a session where
the 2FA code is not entered yet should be cleared.
The token is now removed so the session will be killed the next time
this is checked (within 5 minutes).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If the remember_login_cookie_lifetime is set to 0 this means we do not
want to use remember me at all. In that case we should also not creatae
a remember me cookie and should create a proper temp token.
Further this specifies that is not 0 the remember me time should always
be larger than the session timeout. Because else the behavior is not
really defined.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If a user can't authenticate normally (because they have 2FA that is not
available on their devices for example). The redirect that is generated
should be of the proper format.
This means
1. Include the protocol
2. Include the possible subfolder
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
In 2f87fb6b45 this header was introduced. The referenced documentation says:
> When delivered with a response from https://example.com/clear, the following header will cause cookies associated with the origin https://example.com to be cleared, as well as cookies on any origin in the same registered domain (e.g. https://www.example.com/ and https://more.subdomains.example.com/).
This also applies if `https://nextcloud.example.com/` sends the `Clear-Site-Data: "cookies"` header.
This is not the behavior we want at this point!
So I removed the deletion of cookies from the header. This has no effect on the logout process as this header is supported only recently and the logout works in old browsers as well.
Signed-off-by: Patrick Conrad <conrad@iza.org>
Now that we allow enforcing 2 factor auth it make sense if we also allow
and endpoint where the clients can in the background fetch an
apppassword if they were configured before the login flow was present.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
We use the same logic for creating accounts without a password and there the 12h is a bit short. Users don't expect that the signup link needs to be clicked within 12h - 7d should be a more expected behavior.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
When two or more user share the same email address its not possible to
reset password by email. Even when only one account is active.
This pr reduce list of users returned by getByEmail by disabled users.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
This is required to not break compatibility with existing consumers of that endpoint like the apps management or the client
Signed-off-by: Julius Härtl <jus@bitgrid.net>
This adds persistence to the Nextcloud server 2FA logic so that the server
knows which 2FA providers are enabled for a specific user at any time, even
when the provider is not available.
The `IStatefulProvider` interface was added as tagging interface for providers
that are compatible with this new API.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
PHPDoc (of the public API) says that this method returns string but it also returns null, which is not allowed in some method calls. This fixes that behaviour and returns an empty string and fixes all code paths that explicitly checked for null to be still compliant.
Found while enabling the strict_typing for lib/private for the PHP7+ migration.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* introduce a Controller for requests
* introduce result sorting mechanism
* extend Comments to retrieve commentors (actors) in a tree
* add commenters sorter
* add share recipients sorter
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Any `\OCP\Authentication\IApacheBackend` previously had to implement `getLogoutAttribute` which returns a string.
This string is directly injected into the logout `<a>` tag, so returning something like `href="foo"` would result
in `<a href="foo">`.
This is rather error prone and also in Nextcloud 12 broken as the logout entry has been moved with
054e161eb5 inside the navigation manager where one cannot simply inject attributes.
Thus this feature is broken in Nextcloud 12 which effectively leads to the bug described at nextcloud/user_saml#112,
people cannot logout anymore when using SAML using SLO. Basically in case of SAML you have a SLO url which redirects
you to the IdP and properly logs you out there as well.
Instead of monkey patching the Navigation manager I decided to instead change `\OCP\Authentication\IApacheBackend` to
use `\OCP\Authentication\IApacheBackend::getLogoutUrl` instead where it can return a string with the appropriate logout
URL. Since this functionality is only prominently used in the SAML plugin. Any custom app would need a small change but
I'm not aware of any and there's simply no way to fix this properly otherwise.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
* 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>
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>
