When a Snap was disabled it stopped listening to the events, but if a
drag gesture was being performed it was kept as active. Thus, when the
Snap was enabled again move events were handled as if the Snap had never
been disabled, causing the gesture handling to continue where it was
left.
When the Snap for the navigation bar is disabled by an app it could be
as a result of a different gesture being recognized by the app (for
example, a vertical swipe) once both gestures have started. In that case
when the other gesture ends and the Snap is enabled again any pointer
movement will cause the navigation bar to slide until an "up" event is
triggered again (obviously not the desired behaviour).
Due to all this now when the Snap for the navigation bar is disabled by
an app the current drag gesture for the navigation bar is ended.
Note that this was added as a parameter to "Snap.disable()" instead of
done unconditionally to keep back-compatibility with the previous
behaviour (probably not really needed as it is unlikely that any app is
using the Snap library relying on that behaviour... but just in case).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
On narrow screens a slide gesture can be used to open or close the
navigation bar. However that gesture could conflict at times with the
gestures used by certain apps (for example, if the right sidebar is open
the user may expect to close it by dragging it to the right, but that
could open the navigation bar instead depending on how the events are
handled). This commit makes possible for apps to disallow and allow
again that slide gesture.
In any case, note that applications can only disallow the gesture,
but they can not enable it. That is, they can prevent the gesture from
being used on narrow screens, but they can not make the gesture work on
wide screens; they are always limited by the base rules set by the core.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The slide gesture is enabled or disabled depending on the width of the
browser window. In order to easily control that width the karma-viewport
plugin is now used in the unit tests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In case of error, instead of a generic error message, an upload will
display whichever message is returned in the Sabre Exception, if
applicable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that the permissions returned by the server specify whether a file
is readable or not the frontend no longer needs to assume that every
file is readable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that these tests are executed they are revealed to be partially
obsolete; they were fixed to match the current parsing behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The first parameter of "apply" must be the object to act as "this", and
the Promise callback gets the parameters provided in the "resolve".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The seed of the image placeholder is needed to generate the background
color of the image, but as the background color is later overriden any
seed could be used. When no text is explicitly given the seed is used as
text too, so there is no need to pass the user ID and simply using "?"
as seed is enough.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When calling the jQuery avatar plugin with a user that did not exist
(that is, users for which "/avatar/{user}/{size}" return a JSON response
with an empty "displayname" value) "?" on a grey background was shown.
However, if the jQuery avatar plugin was called with an undefined
JavaScript value then "?" was shown on a bluish background. This commit
unifies both cases to use the grey background.
The unit tests were also modified to ensure that the grey background is
used in both cases.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixed typo and removed doclink symbol.
Reported at transifex
Update util.php
Another l10n improvement from transifex.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
When we test wheter action menus in the contacts menu close
when clicking other ones, we have to provide test data
that actually causes the view to render the menu.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
When a request to set the password of a shared link is sent a working
icon is shown. However, as there was no "success" callback, the icon was
never hidden again after successfully setting the password (it worked
fine if there was an error, though).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Calls to `sinon.stub(obj, 'meth', fn)` are deprecated and therefore
replaced by `sinon.stub(obj, 'meth).callsFake(fn)` as instructed by
the deprecation warning.
This makes the js unit testing output readable again.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
test files against ignore_files list on upload
fix typo and indentation
Move blacklist declaration to lib/public/Files/FileInfo.php,
Rename *ignored to *blacklisted
Mocked blacklist_files for testing
Mocked blacklist_files for testing
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
This mitigates issues where developers pass untrusted user-input through t() which may lead to XSS issues.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
this fixes#3634
1. fixed computerFileSize to be more picky about incorrect values
2. more tests for computerFileSize
3. use computerFileSize to validate user quota
Signed-off-by: Artur Neumann <info@individual-it.net>
* we introduced this setting in the begining because our
avatar support caused some performance issues, but we
fixed them and should only provide one way how Nextcloud
looks
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Enhanced the REPORT method on the Webdav endpoint and added a
"oc:favorite" filter rule. When set, it will return a flat list of
results filtered with only favorite files.
The web UI was also adjusted to use this REPORT method instead of the
private API endpoint.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Whenever the server returns true for the can-assign Webdav property of
a system tag, it means the current user is allowed to assign,
regardless of the value of user-assignable.
This commit brings the proper logic to the web UI to make it possible
for users to assign when they have the permission.
**Before:**
> Your PHP version (5.4.16) is no longer supported by PHP. We encourage you to upgrade your PHP version to take advantage of performance and security updates provided by PHP.
**After:**
> You are currently running PHP 5.4.0. We encourage you to upgrade your PHP version to take advantage of performance and security updates provided by the PHP Group as soon as your distribution supports it.
Fixes https://github.com/owncloud/enterprise/issues/1170
The notification tests were not restoring the clock properly, but
indirectly helped other tests pass.
Since now we're restoring the clock properly, the other tests were fixed
to still work.
Permission text now doesn't appear when all permissions are there, or
shows as "invisible" or "not assignable", which should better cover all
use cases.
Changed select2 style to use boxes in the input field.
Does not disrupt the UX whenever a tag or association was created
concurrently. The input field will adjust itself as if the tag was
already there in the first place.
For admins: display the namespace behind the tag name.
For users: no namespace, don't display non-assignable tags in the
dropdown, display already assigned non-assignable tags with a different
style
Whenever link share is not allowed, it was outputting a bogus sharing
field which name would conflict with the regular sharing field.
This fix makes sure that the bogus sharing field with "Resharing not
allowed" message only appears when triggered by removed share
permissions.
This PR implements the base foundation of the code signing and integrity check. In this PR implemented is the signing and verification logic, as well as commands to sign single apps or the core repository.
Furthermore, there is a basic implementation to display problems with the code integrity on the update screen.
Code signing basically happens the following way:
- There is a ownCloud Root Certificate authority stored `resources/codesigning/root.crt` (in this PR I also ship the private key which we obviously need to change before a release 😉). This certificate is not intended to be used for signing directly and only is used to sign new certificates.
- Using the `integrity:sign-core` and `integrity:sign-app` commands developers can sign either the core release or a single app. The core release needs to be signed with a certificate that has a CN of `core`, apps need to be signed with a certificate that either has a CN of `core` (shipped apps!) or the AppID.
- The command generates a signature.json file of the following format:
```json
{
"hashes": {
"/filename.php": "2401fed2eea6f2c1027c482a633e8e25cd46701f811e2d2c10dc213fd95fa60e350bccbbebdccc73a042b1a2799f673fbabadc783284cc288e4f1a1eacb74e3d",
"/lib/base.php": "55548cc16b457cd74241990cc9d3b72b6335f2e5f45eee95171da024087d114fcbc2effc3d5818a6d5d55f2ae960ab39fd0414d0c542b72a3b9e08eb21206dd9"
},
"certificate": "-----BEGIN CERTIFICATE-----MIIBvTCCASagAwIBAgIUPvawyqJwCwYazcv7iz16TWxfeUMwDQYJKoZIhvcNAQEF\nBQAwIzEhMB8GA1UECgwYb3duQ2xvdWQgQ29kZSBTaWduaW5nIENBMB4XDTE1MTAx\nNDEzMTcxMFoXDTE2MTAxNDEzMTcxMFowEzERMA8GA1UEAwwIY29udGFjdHMwgZ8w\nDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANoQesGdCW0L2L+a2xITYipixkScrIpB\nkX5Snu3fs45MscDb61xByjBSlFgR4QI6McoCipPw4SUr28EaExVvgPSvqUjYLGps\nfiv0Cvgquzbx/X3mUcdk9LcFo1uWGtrTfkuXSKX41PnJGTr6RQWGIBd1V52q1qbC\nJKkfzyeMeuQfAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAvF/KIhRMQ3tYTmgHWsiM\nwDMgIDb7iaHF0fS+/Nvo4PzoTO/trev6tMyjLbJ7hgdCpz/1sNzE11Cibf6V6dsz\njCE9invP368Xv0bTRObRqeSNsGogGl5ceAvR0c9BG+NRIKHcly3At3gLkS2791bC\niG+UxI/MNcWV0uJg9S63LF8=\n-----END CERTIFICATE-----",
"signature": "U29tZVNpZ25lZERhdGFFeGFtcGxl"
}
```
`hashes` is an array of all files in the folder with their corresponding SHA512 hashes (this is actually quite cheap to calculate), the `certificate` is the certificate used for signing. It has to be issued by the ownCloud Root Authority and it's CN needs to be permitted to perform the required action. The `signature` is then a signature of the `hashes` which can be verified using the `certificate`.
Steps to do in other PRs, this is already a quite huge one:
- Add nag screen in case the code check fails to ensure that administrators are aware of this.
- Add code verification also to OCC upgrade and unify display code more.
- Add enforced code verification to apps shipped from the appstore with a level of "official"
- Add enfocrced code verification to apps shipped from the appstore that were already signed in a previous release
- Add some developer documentation on how devs can request their own certificate
- Check when installing ownCloud
- Add support for CRLs to allow revoking certificates
**Note:** The upgrade checks are only run when the instance has a defined release channel of `stable` (defined in `version.php`). If you want to test this, you need to change the channel thus and then generate the core signature:
```
➜ master git:(add-integrity-checker) ✗ ./occ integrity:sign-core --privateKey=resources/codesigning/core.key --certificate=resources/codesigning/core.crt
Successfully signed "core"
```
Then increase the version and you should see something like the following:
![2015-11-04_12-02-57](https://cloud.githubusercontent.com/assets/878997/10936336/6adb1d14-82ec-11e5-8f06-9a74801c9abf.png)
As you can see a failed code check will not prevent the further update. It will instead just be a notice to the admin. In a next step we will add some nag screen.
For packaging stable releases this requires the following additional steps as a last action before zipping:
1. Run `./occ integrity:sign-core` once
2. Run `./occ integrity:sign-app` _for each_ app. However, this can be simply automated using a simple foreach on the apps folder.