This should allow better reports as often the app id is passed
as context. While this is not used right now, I'd like to have this
for NC13 as adding it later will break the interface for existing apps
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This adds a crash reporter registry, which is meant for third party apps
to hook into the error logging/reporting chain. This way, external tools
like Sentry can be used to track and aggregate system crashes.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This seems to be the only way to have the same helpers used between
tests in a manner that works for both standalone phpunit and
autotest.sh.
Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
background: we have a flat hierarchy of comments, not a tree. therefore we
can also remove again the unnecessary additions.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
Object storage instances always fall back to the content based mimetype detection, because the file name for object storage was always random due to the fact that it was temporarily storage in a generated temp file. This patch adds a check before that to make sure to use the original file name for this purpose and also remove possible other extensions like the versioning or part file extension.
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>
Firefox and Chrome drivers for Selenium refuse to click on an element if
the point to be clicked is covered by a different element, throwing an
UnknownError exception with message "Element is not clickable at point
({x}, {y}). Other element would receive the click: {element}". Although
in general that would be a legit error (as the user would not be able to
click on the element) due to a bad layout, sometimes this can be just a
temporal issue caused by an animation, in which case there would be no
problem once the animation finished and the elements are all in their
final location.
Unfortunately, automatically handling those situations in which the
problem is caused by an animation by just retrying a few times if the
element to be clicked is covered before giving up would probably cause
confusion instead of easing test writing.
The reason is that if the center of the element is covered by another
one the Firefox driver for Selenium tries to click on the corners of the
element instead. The problem is that the coordinates used for the click
are integer values, but Firefox has sub-pixel accuracy, so sometimes
(depending on which corner is not covered and whether the left, top,
width or height properties of the element to be clicked have a decimal
component or not) the clicks silently land on a different HTML element
(and that is with squared borders; with round borders they always land
on a different HTML element. That was partially addressed for Selenium
3.0 by clicking first on the edges, but it would still fail if the
middle point of the edges is covered but not the corners).
It is not possible to fix or even detect all that from the tests (except
maybe with some extreme hacks involving accessing private PHP members
from Mink and bypassing or replacing the standard JavaScript executed by
the Firefox driver with a custom implementation...), so it is not
possible to ensure that clicks during an animation will land on the
right element (in fact it is not possible even on static elements,
although except when the layout is wrong there should be no problem);
sometimes retrying a click when the element is covered would solve the
problem, sometimes it would cause a different element to be clicked (and
sometimes there would be even no retry, as the first click would have
silently landed on a different element than the expected one).
Therefore, a different approach must be used. Instead of trying to
automatically handle clicks during animations the tests must be written
being aware of the problem and thus waiting somehow for the animations
that can cause a problem to end before performing the clicks.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This is a preparatory step for a following commit in which the position
of the favorite icon and the checkbox will be swapped; in that new
design the favorite icon is no longer expected to be an action but just
a simple mark on whether the file is favorited or not (the action is
expected to be triggered then only from the file actions menu).
The favorite icon is now fully shown or completely hidden depending on
whether the file is favorited or not. As the icon is just informative
but no longer an action now it does not change when hovered or focus. In
the same way, the alternative text when the file is not favorited now it
is not "Favorite" (an action) but "Not favorited" instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently a file can be favorited either through the inline action or
through the file actions menu. However, the inline action will be
removed in a following commit and then it will be possible to do it only
through the file actions menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
On a remembered login session, we create a new session token
in the database with the values of the old one. As we actually
don't need the old session token anymore, we can delete it right
away.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
This adjusts the contacts menu to also support searching by email address which is relevant in scenarios where no UID is known such as LDAP, etc.
Furthermore, if `shareapi_allow_share_dialog_user_enumeration` is disabled only results are shown that match the full user ID or email address.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
* Store the auth state in the session so we don't have to query it every
time.
* Added some tests
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
`\OC\User\Database::createUser` can throw a PHP exception in case the UID is longer than
permitted in the database. This is against it's PHPDocs and we should cast this to `false`,
so that the regular error handling triggers in.
The easiest way to reproduce is on MySQL:
1. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel
2. Create user `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` in admin panel again
3. See SQL exception as error message
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
There was a setting to disable the last execution of cron. There is no known
problem with this write access and it was also questioned when this feature
was build in https://github.com/owncloud/core/pull/7689#issuecomment-38264707
Recently there was also a bug report about a non-visible last cron execution
(#6088) - let's better remove this.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
In some cases the acceptance tests have to explicitly wait for something
to happen without using the "find" method from the actor; in those cases
the timeout multiplier needs to be taken into account too, so the test
cases must be able to retrieve it from the actor.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Now listeners for those events get proper share objects.
* Legacy hooks still fired
* Updated tests
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This is public API and breaks the middlewares of existing apps. Since this also requires maintaining two different code paths for 12 and 13 I'm at the moment voting for reverting this change.
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>
* PrivateData is an app now: https://github.com/nextcloud/privatedata
* No need to load the OCS routes.php (as there is none!)
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
- This kind of hook signal used to be emitted in the old Share library but it was missing from Share 2.0
Signed-off-by: Pauli Järvinen <pauli.jarvinen@gmail.com>
By default "127.0.0.1:4444" is used, so nothing needs to be set when the
acceptance tests and the Selenium server share the same network (like
when called by "run.sh").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
By default "127.0.0.1" is used, so nothing needs to be set when the
Selenium server and the Nextcloud test server share the same network
(like when called by "run.sh").
Besides passing the domain to the acceptance tests the Nextcloud test
server configuration must be modified to see the given domain as a
trusted domain; otherwise the access would be forbidden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The NextcloudTestServerLocalHelper started the PHP built-in web server
for the Nextcloud test server at 127.0.0.1; as the Selenium server has
to access the Nextcloud test server they were forced to share the same
network. Now, the domain at which the PHP built-in web server is started
can be specified when the NextcloudTestServerLocalHelper is created,
which removes the need of sharing the same network, as the Selenium
server now can access the Nextcloud test server at an arbitrary domain.
However, by default "127.0.0.1" is still used if no domain is given.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
- When a file was unshared, the legacy hook pre_unshare fired twice and the hook post_unshare did not fire at all. This was obviously a copy-paste error.
Signed-off-by: Pauli Järvinen <pauli.jarvinen@gmail.com>
Fix service container host name
check current folder
fix redis for integration test
Fix more hostnames
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The app navigation is not exclusive to the Files app but a generic
component used by other apps too, so its locators and steps should be in
its own context.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixme:
- Install and update of apps
- No revert on live systems (debug only)
- Service adjustment to our interface
- Loading via autoloader
Signed-off-by: Joas Schilling <coding@schilljs.com>
The SystemTagsInfoViewToggleView is a basic view that renders a label
that, when clicked, toggles the visibility of an associated
SystemTagsInfoView.
In order to keep the view parent agnostic its attachment and detachment
to/from the MainfFileInfoView is done in the FilesPlugin.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Acceptance tests opened the details view by clicking on the middle of
the file row, but due to the changes made in issue #4921 that now opens
the file instead; this commit updates the acceptance tests to open the
details view through the "Details" item in the file actions menu.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Commands executed on Mink elements may fail for several reasons.
ElementWrapper is introduced to automatically handle some of those
situations, like StaleElementReference exceptions and ElementNotVisible
exceptions.
StaleElementReference exceptions are thrown when the command is executed
on an element that is no longer attached to the DOM. When that happens
the ElementWrapper finds again the element and executes the command
again on the new element.
ElementNotVisible exceptions are thrown when the command requires the
element to be visible but the element is not. When that happens the
ElementWrapper waits for the element to be visible before executing the
command again.
These changes are totally compatible with the current acceptance tests.
They just make the tests more robust, but they do not change their
behaviour. In fact, this should minimize some of the sporadic failures
in the acceptance tests caused by their concurrent nature with respect
to the web browser executing the commands.
However, the ElementWrapper is not a silver bullet; it handles the most
common situations, but it does not handle every possible scenario. For
example, the acceptance tests would still fail sporadically if an
element can become staled several times in a row (uncommon) or if it
does not become visible before the timeout expires (which could still
happen in a loaded system even if the components under test work right,
but obviously it is not possible to wait indefinitely for them).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Starting a session for an Actor can fail, typically, due to a timeout
connecting with the web browser. Now if the session fails to start it
will be tried again up to "actorTimeoutMultiplier" times in total before
giving up.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The timeout passed to the "find" method was multiplied by the
"findTimeoutMultiplier" attribute. However, as "find" used
"findAncestor" and "findAncestor", in turn, used "find" itself the
timeout was increased exponentially for ancestor elements. Now "find"
was split in "find" and "findInternal"; the first method is the public
one and modifies the given parameters as needed and then calls the
second method, private, that performs the find itself.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "named" Mink selector first tries to find an exact match for its
locator and then, if not found, tries to find a partial match. Besides
other harder to track problems (see comment in the commit in which the
"content" locator was removed), this could cause, for example, finding
an action link titled "Favorited" when looking for the action link
titled "Favorite" (that is, one that conveys the opposite state to the
one found).
Although currently all the acceptance tests are compatible with both the
"named" and the "named_exact" Mink selectors the predefined locators are
modified to use the "named_exact" Mink selector to make them more
future-proof; the "named" Mink selector can still be used if needed
through the "customSelector" method in the builder object.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "content" locator uses the "named" Mink selector and the "content"
Mink locator to find the element. The "named" Mink first tries to find
the elements whose content match exactly the given content but, if none
is found, then it tries to find elements that just contain the given
content.
This behaviour can lead to hard to track issues. Finding the exact match
and, if not found, finding the partial match is done in quick
succession. In most cases, when looking for an exact match the element
is already there, it is returned, and everything works as expected. Or
it may not be there, but then it is not there either when finding the
partial match, so no element is returned, and everything works as
expected (that is, the actor tries to find again the element after some
time).
However, it can also happen that when looking for an exact match there
is no element yet, but it appears after trying to find the exact match
but before trying to find the partial match. In that situation the
desired element would be returned along with its ancestors. However, as
only the first found element is taken into account and the ancestors
would appear first the find action would be successful, but the returned
element would not be the expected one. This is highly unlikely, yet
possible, and can cause sporadic failures in acceptance tests that,
apparently, work as expected.
Using a "named_exact" Mink selector instead of the "named" Mink selector
does not provide the desired behaviour in most cases either. As it finds
any element whose content matches exactly the given content, looking for
"Hello world" in "<div><p><a>Hello world</a></p></div>" would match the
"div", "p" and "a" elements; in that situation the "div" element would
be the one returned, when typically the "a" element would be the
expected one.
As it is error prone and easily replaceable by more robust locators the
"content" locator was removed from the predefined ones (although it can
still be used if needed through the "customSelector" method in the
builder object).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently, when disabling the brute force protection no new brute force attempts are logged. However, the ones logged within the last 24 hours will still be used for throttling.
This is quite an unexpected behaviour and caused some support issues. With this change when the brute force protection is disabled also the existing attempts within the last 24 hours will be disregarded.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
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>
