As discussed in #18603 caching a 201 response is hard. It's now possible to distinguish between generated and uploaded avatars by reading the X-NC-IsCustomAvatar (0 = generated, 1 = uploaded) header.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
Otherwise we keep on using it with leading or trailing whitespaces for
app tokens and other logic. The reason this doesn't throw an error
immediately with local users is that (My)SQL compares strings regardless
of their padding by default. So we look up 'uid ' and get the row for
the user 'uid'.
Other back-ends will lead to a hard error, though, and the user is
unable to log out as all request fail.
Ref https://stackoverflow.com/a/10495807/2239067
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Resolves Issue #17885
Check getRedirectUri() for queries, and add a '&' instead of a '?' to $redirectUri if it already has them; otherwise, $redirectUri might end up with two '?'.
Signed-off-by: RussellAult <russellault@users.noreply.github.com>
Fixes#5456
Only when an avatar is set to public should we show it to the public.
For now this has an open question as to how to solve federated avatars.
But I assume a dedicated paramter or endpooint would make sense there.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fix Argument 1 passed to OC\Security\Crypto::decrypt() must be of the type string, null given
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
So fun fact. Chrome considers a redirect after submitting a form part of
the form actions. Since we redirect to a new protocol (nc://login/).
Causing the form submission to work but the redirect failing hard.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
There is no need to log the expcetion of most of the stuff here.
We should properly log them but an exception is excessive.
This moves it to a proper exception which we can catch and then log.
The other exceptions will still be fully logged.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The constructor is called with the userId. However if a user is not
logged in this is null. Which means that we get an exception instead of
this being handled gracefully in the middleware.
There are cleaner solutions. But this is the solution that is the
easiest to apply without lots of work and risk of breaking things
(handling the logged in middleware before initializing the controller
etc).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This allows a user to mark a token for remote wipe.
Clients that support this can then wipe the device properly.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Once 2FA is enforced for a user and they have no 2FA setup yet this will
now prompt them with a setup screen. Given that providers are enabled
that allow setup then.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This adds the new login flow. The desktop client will open up a browser
and poll a returned endpoint at regular intervals to check if the flow
is done.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#12568
Since the clearing of the execution context causes another reload. We
should not do the redirect_uri handling as this results in redirecting
back to the logout page on login.
This adds a simple middleware that will just check if the
ClearExecutionContext session variable is set. If that is the case it
will just redirect back to the login page.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
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>
Because the redirect from the SAML/SSO endpoint is a POST the lax/strict
cookies are not properly send.
Note that it is not strictly requried on this endpoint as we do not need
the remember me data. Only the real session info is enough. The endpoint
is also already protected by a state token.
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>
* On weblogin check if we have invalid public key tokens
* If so update them all with the new token
This ensures that your marked as invalid tokens work again if you once
login on the web.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#10584
We deleted the main token when using the login flow else mutliple tokens
would show up for a single user.
However in the case of OAuth this is perfectly fine as the
authentication happens really in your browser:
1. You are already logged in, no need to log you out
2. You are not logged in yet, but since you log in into the exact same
browser the expected behavior is to stay logged in.
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>
Roeland Jago Douma
Roeland Jago Douma
Christoph Wurst
Christoph Wurst
Daniel Kesselberg
Joas Schilling
Joas Schilling
RussellAult
Sergej Nikolaev
Julius Härtl
Morris Jobke
Michael Weimann
John Molakvoæ (skjnldsv)
Rayn0r
Thomas Citharel
Patrick Conrad
blizzz