Scenarios in acceptance tests must be independent one of each other.
That is, the execution of one scenario can not affect the execution of
another scenario, nor it can depend on the result of the execution of a
different scenario. Each scenario must be isolated and self-contained.
As the acceptance tests are run against a Nextcloud server the server
must be in a known and predefined initial state each time a scenario
begins.
The NextcloudTestServerContext is introduced to automatically set up the
Nextcloud test server for each scenario.
This can be achieved using Docker containers. Before an scenario begins
a new Docker container with a Nextcloud server is run; the scenario is
then run against the server provided by the container. When the scenario
ends the container is destroyed. As long as the Nextcloud server uses
local data storage each scenario is thus isolated from the rest.
The NextcloudTestServerContext also notifies its sibling RawMinkContexts
about the base URL of the Nextcloud test server being used in each
scenario.
Although it uses the Behat context system, NextcloudTestServerContext is
not really part of the acceptance tests, but a provider of core features
needed by them; it can be seen as part of a Nextcloud acceptance test
library. Therefore, those classes are stored in the "core" directory
instead of the "bootstrap" directory. Besides its own (quite limited)
autoload configuration, Behat also uses the Composer autoloader, so the
"core" directory has to be added there for its classes to be found by
Behat.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The acceptance tests verify that a Nextcloud server works as expected
from the point of view of an end-user. They are specified as user
stories using Behat paired with Mink, which provides web browser
automation.
Mink supports several browser emulators, but the system is set up to use
Selenium, as it is FOSS and the one that better reflects the use of a
web browser by an end-user (as, in fact, it controls real web browsers).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Otherwise your mail program shows "foo@mail.com" instead of "Nextcloud" or whatever your instance name is.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
While the risk is actually quite low because one would already have the user session and could potentially do other havoc it makes sense to throttle here in case of invalid previous password attempts.
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>
The local link is a clever thing and the clients should support this imho but it might not be clear to all users. For one, the term 'local link' is a bit odd. Local with respect to what? It links directly to the file or folder, so direct link seems to make more sense to me. And we should explain the difference with a public link. So this PR:
* renames local link to direct link
* adds a short explanation, noting it only works for users who have access to this file/folder.
As other links are called public link you could also consider calling this 'private link', I suppose. But the links we sent by mail to ppl could also be called 'private link' (they are for one user, who git it by email) so I think it might be confusing. What do @nextcloud/designers think?
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Daniel Calviño Sánchez
Morris Jobke
Nextcloud bot
Jan-Christoph Borchardt
Joas Schilling
Lukas Reschke
Christoph Wurst
Roeland Jago Douma
Jos Poortvliet
Roeland Jago Douma