| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Add metadata to \OCP\AppFramework\Http\Response::throttle
|
| |
| |
| |
| |
| |
| | |
Fixes https://github.com/nextcloud/server/issues/5891
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
| |
| |
| |
| | |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
| |
| |
| |
| | |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|/
|
|
| |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|
|
|
| |
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|
|
|
| |
Signed-off-by: Julius Härtl <jus@bitgrid.net>
|
|
|
|
|
|
|
|
|
|
| |
This adds a Clear-Site-Data header to the logout response which will delete all relevant data in the caches which may contain potentially sensitive content.
See https://w3c.github.io/webappsec-clear-site-data/#header for the definition of the types.
Ref https://twitter.com/mikewest/status/877149667909406723
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
|
|
|
|
|
|
| |
API request
Signed-off-by: Bjoern Schiessle <bjoern@schiessle.org>
|
|
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
| |
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|
|
|
| |
Signed-off-by: Georg Ehrke <developer@georgehrke.com>
|
|\
| |
| |
| | |
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
|
| |
| |
| |
| | |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
| |
| |
| |
| |
| |
| |
| | |
we should check the stateToken before we remove it. Else the check will
always fail.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| | |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|/
|
|
|
|
|
| |
* load list of contacts from the server
* show last message of each contact
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|
|
|
| |
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
|
|\
| |
| | |
Remove unused use statements
|
| |
| |
| |
| | |
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|\ \
| | |
| | |
| | |
| | | |
nextcloud/add-rate-limiting-to-solve-challenge-controller
Add rate limit to TOTP solve challenge controller
|
| |/
| |
| |
| |
| |
| | |
Fixes https://github.com/nextcloud/server/issues/2626
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|/
|
|
| |
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
|
|
|
| |
* fixes #4383
* improves consistency
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|
|
|
|
|
|
| |
- Moves code to annotation
- Adds the `throttle()` call on the responses on existing annotations
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|
|
|
|
|
|
|
| |
This makes the new `@BruteForceProtection` annotation more clever and moves the relevant code into it's own middleware.
Basically you can now set `@BruteForceProtection(action=$key)` as annotation and that will make the controller bruteforce protected. However, the difference to before is that you need to call `$responmse->throttle()` to increase the counter. Before the counter was increased every time which leads to all kind of unexpected problems.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|\
| |
| | |
Update email template for lost password email
|
| |
| |
| |
| | |
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|\ \
| | |
| | |
| | |
| | | |
nextcloud/fix-login-controller-test-consolidate-login
Fix login controller test and consolidate login
|
| | |
| | |
| | |
| | | |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
|
| | |
| | |
| | |
| | | |
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This allows adding rate limiting via annotations to controllers, as one example:
```
@UserRateThrottle(limit=5, period=100)
@AnonRateThrottle(limit=1, period=100)
```
Would mean that logged-in users can access the page 5 times within 100 seconds, and anonymous users 1 time within 100 seconds. If only an AnonRateThrottle is specified that one will also be applied to logged-in users.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
|
|\ \ \
| |_|/
|/| | |
Dont create a log entry on email login
|
| |/
| |
| |
| | |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
* 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>
|
|\
| |
| | |
Allow to reset the password with the email as an input
|
| |
| |
| |
| | |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
| |
| |
| |
| |
| |
| | |
* Safari support gzip only if the filename does not
end on .gz - so this renames them to .gzip
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
|
|/
|
|
|
|
|
|
|
|
| |
Since in production the SCSS files are compiled once and the javascript
files are combined once we can just as well gzip them aggresively.
This means that once they are requested and the browser supports gzip we
can just serve the gzipped file saving precious bandwidth.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|
|
|
|
| |
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
|