When `mod_unique_id` is enabled the ID generated by it will be used for logging. This allows for correlation of the Apache logs and the ownCloud logs.
Testplan:
- [ ] When `mod_unique_id` is enabled the request ID equals the one generated by `mod_unique_id`.
- [ ] When `mod_unique_id` is not available the request ID is a 20 character long random string
- [ ] The generated Id is stable over the lifespan of one request
Changeset looks a little bit larger since I had to adjust every unit test using the HTTP\Request class for proper DI.
Fixes https://github.com/owncloud/core/issues/13366
Since the Storage interface isn't ready to work directly with exceptions
like Forbidden and NotFound, the DAV storage has been adapted to still
return false when expected.
Can happen when trying to instantiate external storages that have
incomplete config, where the constructor throws an exception (the
exception is caught in createStorage())
There might be the case that `fopen($file, 'r')` returns false and thus ownCloud might believe that the config file is empty and thus potentially leading to an overwrite of the config file.
This changeset introduces `file_exists` again which was used in ownCloud 5 where no such problems where reported and should not be affected by such problems.
Ref https://github.com/owncloud/core/issues/12785#issuecomment-71548720
Whenever an exception occurs during scan of a remote share, the share is
checked for availability. If the storage is gone, it will be removed
automatically.
Also, getDirectoryContent() will now skip unavailable storages.
HHVM seems to have problems with this at the moment (even setting those values in the php.ini of HHVM doesn't have helped much) and thus the unit test execution failed.
So it's better if we disable this check for now for HHVM.
A recent change that prevents reshare permission changes to delete group
share children had the side-effect of also preventing group share
children deletion when it needed to be done.
This fix adds an extra flag to isolate the "reshare permission change"
deletion case and keep the other ones as they were before, not only to
fix the regression but also fix other potential regressions in code that
uses this method.
Also updated the comment because now Helper::delete() is no longer
limited to reshares but also applies to group share children.
\Sabre\DAV\Auth\Backend\AbstractBasic::authenticate was only calling \OC_Connector_Sabre_Auth::validateUserPass when the response of \Sabre\HTTP\BasicAuth::getUserPass was not null.
However, there is a case where the value can be null and the user could be authenticated anyways: The authentication via ownCloud web-interface and then accessing WebDAV resources. This was not possible anymore with this patch because it never reached the code path in this scenario.
This patchs allows authenticating with a session without isDavAuthenticated value stored (this is for ugly WebDAV clients that send the cookie in any case) and thus the functionality should work again.
To test this go to the admin settings and test if the WebDAV check works fine. Furthermore all the usual stuff (WebDAV / Shibboleth / etc...) needs testing as well.
This function is called a lot of times and was really slow before due to not reusing the same array.
Previously when it was called 500'000 times it took about 2seconds, now we're down to 0.2 seconds on my local machine.
Ref https://github.com/owncloud/core/issues/13434
There are a lot of clients that support multiple WebDAV accounts in the same application. However, they resent all the cookies they received from one of the accounts also to the other one. In the case of ownCloud this means that we will always show the user from the session and not the user that is specified in the basic authentication header.
This patch adds a workaround the following way:
1. If the user authenticates via the Sabre Auth Connector add a hint to the session that this was authorized via Basic Auth (this is to prevent logout CSRF)
2. If the request contains this hint and the username specified in the basic auth header differs from the one in the session relogin the user using basic auth
Fixes https://github.com/owncloud/core/issues/11400 and https://github.com/owncloud/core/issues/13245 and probably some other issues as well.
This requires proper testing also considering LDAP / Shibboleth and whatever instances.
This has no other reason than preventing some insane automated scanners from reporting this as security bug (which it obviously isn't as the cookie contains nothing of value)
Thus it generally results in an happier Lukas and hopefully less reports to our support and security mail addresses...
It's better to encode the string to prevent possible (yet unknown) bugs in combination with PHP's type juggling.
Previously the boolean statements evaluated to either an empty string (false) or a not empty one (true, then it was 1). Not it always evaluates to false or true.
This also removes a stray - that was not intended there but shouldn't have produced any bugs. Just to increase readability.
Thanks @nickvergessen for spotting.
Addresses https://github.com/owncloud/core/pull/13235/files#r22852319
The internal path was matched without the last "/" which caused
"files_trashbin" to also match when the internal path was "files".
This adds the missing slash for the comparison.
Apparently `normalizer_normalize` is not verifying itself whether the string needs to be converted or not. Or does it at least not very performantly.
This simple change leads to a 4% performance gain on the processing of normalizeUnicode. Since this method is called quite often (i.e. for every file path) this has actually a measurable impact. For examples searches are now 200ms faster on my machine. Still not perfect but way to go.
Part of https://github.com/owncloud/core/issues/13221
Isset is a native language construct and thus A LOT faster than using strlen()
On my local machine this leads to a 1s performance gain for about 1 million paths. Considering that this function will be called a lot for every file operation this makes a noticable difference.
`normalizePath` is a rather expensive operation and called multiple times for a single path for every file related operation.
In my development installation with about 9GB of data and 60k files this leads to a performance boost of 24% - in seconds that are 1.86s (!) - for simple searches. With more files the impact will be even more noticeable. Obviously this affects every operation that has in any regard something to do with using OC\Files\Filesystem.
Part of https://github.com/owncloud/core/issues/13221
The check for invalid paths is actually over-complicated and performed twice resulting in a performance penalty. Additionally, I decided to add unit-tests to that function.
Part of https://github.com/owncloud/core/issues/13221
The current behaviour of the authenticion logic in base.php prevents REST APIs in ownCloud applications to work.
Because `!self::$CLI` is usually always a true statement the previously above block was entered which returned, thus the authentication logic for this part does not trigger in.
This can be reproduced by installing apps such as the News app and issuing the following command:
`curl -u admin:admin http://localhost/index.php/apps/news/api/v1-2/feeds`
The following parts needs to get throughly tested:
- [ ] OCS
- [ ] remote.php's DAV features
- [ ] Regular login features
This bug affects master and stable7. I'd propose that we merge this for 8.0 since this has the potential to break every component that relies on Basic Auth features. A backport would also be very nice.
Remark to myself: We really need to move out the authentication code for 8.1 out of base.php - I already have a local branch that does that somewhere which I will get in shape for 8.1... - This untested code is a night-mare.
Fixes itself.
Otherwise every time the AppStore was opened a lot of connections to the AppStore server were made which resulted in a terrible performance.
This changeset will cache the response for a sensible time so that only the first request will be somewhat slow.
Performance changes:
- Loading a category took previously more than 3 seconds on my machine. Now for every follow-up request it takes less than 200ms, resulting in a performance gain of 1950%
- Loading the category list took previously about 750ms - now it takes 154ms, a total performance gain of 395%
`$this->info` can very well contain an empty array or possibly other values. This means that when this code path is called a PHP Fatal error might get thrown which is not what we want.
Currently if a user does not replace the .htaccess file with the new update this can lead to serious problems in case Apache is used as webserver.
This commit adds the version to the .htaccess file and the update routine fails in case not the newest version is specified in there. This obviously means that every release has to update the version specified in .htaccess as well. But I see no better solution for it.
Conflicts:
lib/private/updater.php
When uploading files to an OC ext storage backend or when using server
to server sharing storage, part files aren't needed because the backend
already has its own part files and takes care of the final atomic rename
operation.
This also fixes issues when using two encrypted ownCloud instances where
one mounts the other either as external storage (ownCloud backend) or
through server to server sharing.
add logSettingsController
add download logfile button
move getEntries to LogSettingsController
move set log level to logsettingscontroller.php
add warning if logfile is bigger than 100MB
add unit test for set log level
fix typecasting, add new line at EoF
show log and logfile download only if log_type is set to owncloud
add unit test for getFilenameForDownload
I was getting a lot of these in my logs for no apparent reason, and file
uploads were failing:
{"app":"webdav","message":"Sabre\\DAV\\Exception\\ServiceUnavailable: ","level":4,"time":"2015-01-06T15:33:39+00:00"}
In order to debug it, I had to add unique messages to all the places where
this exception was thrown, to identify which one it was, and that made the
logs much more useful:
{"app":"webdav","message":"Sabre\\DAV\\Exception\\ServiceUnavailable: Encryption is disabled","level":4,"time":"2015-01-06T15:36:47+00:00"}
This allows the directory where CSS/JS asset collections are
written to be changed, in case SERVERROOT is not writeable. Note
it does *not* allow the expected URL to be changed: whatever
directory is used, the server must be configured to serve it
at WEBROOT/assets. It may be possible to add another config
parameter to allow the admin to specify a custom asset URL,
but I thought I'd keep the first implementation simple.
At some point SeparatorFilter should be included upstream
(kriswallsmith/assetic), then lib/private/assetic/separatorfilter.php can be
removed and the `use` in lib/private/templatelayout.php rewritten.
SeparatorFilter inserts a separator between assets, preventing issues when
files are incorrectly terminated. For JS this is a semicolon.
* resolves dependencies by type hint or variable name
* simpler route.php
* implementation of https://github.com/owncloud/core/issues/12829
Generates and injects parameters automatically. You can now build full classes like
$c->query('MyClassName')
without having to register it as a service. The resolved object's instance will be saved by using registerService. If a constructor parameter is not type hinted, the parameter name will be taken.
Therefore the following two implementations are identical:
class Class1 { function __construct(MyClassName $class)
class Class1 { function __construct($MyClassName)
This makes it possible to also inject primitive values such as strings, arrays etc.
In addition if the query could not be resolved, a `QueryException` is now thrown
Routes can now be returned as an array from `routes.php` and an `appinfo/application.php` is optional
Old commit messages:
make it possible to return the routes instead of having to intialize the application
try to get the controller by convention
add first implementation of automatic resolve
add another test just to be sure
store the resolved object
more tests
add phpdoc to public app.php method
use the same variable for the public app.php method
deprecate old methods and add services for public interfaces
deprecated getServer method
disallow private api injection for apps other than core or settings (settings should be an app goddamnit :D)
register userid because its such an often used variable
fix indention and leading slash
use test namespace
add deprecation reasons, remove private api usage checks and remove deprecation from getServer()
add additional public interfaces
add public interface for rootfolder
fix syntax error
remove deprecation from methods where no alternative is there yet
remove deprecated from method which has no alternative
add timezone public service for #12881
add another deprecation hint
move deprecation into separate branch
remove dead comment
first try to get the namespace from the info.xml, if it does not exist, just uppercase the first letter
also trim the namespace name
add an interface for timefactory
move timefactory to public and add icontrollermethodreflector
keep core interface
fix copyright date in headers
Fix app":"PHP","message":"Undefined variable: result at \/var\/www\/owncloud\/lib\/private\/tags.php#231" by moving the function call into the respective loop
Adjust indentation
Do it right - indentation
sorry, this is my first one
remove unused methods
split mapping methods off from Access class
fix DB query handling
move 'clear mapping' methods from static helper to new mapping class
add tests
test directly with DB
finishing tests and fix return value from setDNbyUUID
add corresponding class for groups and make abstract test class neutral. helper tests is now obsolete as the tested functions were moved to the new mapper class.
add missing info to PHPDoc
add unmap method
fix namespaces
fix test inheritance
PHPDoc and a small code restructure for scrutinizer, no effective changes
PostgreSQL does not accept LIMIT in DELETE queries
phpdoc fixes, no code changes
Beside some small improvements and bug fixes this will probably the final state for OC8.
To test this you need to set up two ownCloud instances. Let's say:
URL: myPC/firstOwnCloud user: user1
URL: myPC/secondOwnCloud user: user2
Now user1 can share a file with user2 by entering the username and the URL to the second ownCloud to the share-drop-down, in this case "user2@myPC/secondOwnCloud".
The next time user2 login he will get a notification that he received a server-to-server share with the option to accept/decline it. If he accept it the share will be mounted. In both cases a event will be send back to user1 and add a notification to the activity stream that the share was accepted/declined.
If user1 decides to unshare the file again from user2 the share will automatically be removed from the second ownCloud server and user2 will see a notification in his activity stream that user1@myPC/firstOwnCloud has unshared the file/folder from him.
The default value of the $format parameter of the APCIterator constructur is
APC_ITER_ALL which instructs the iterator to provide all available information
on cache values being iterated over. Only the key value is necessary for
matching and deletion via apc_delete(), though.
This prevents a "Format values FILENAME, DEVICE, INODE, MD5, NUM_HITS, MTIME,
CTIME, DTIME, ATIME, REFCOUNT not supported yet." notice on HHVM.
Potentially fixes https://github.com/owncloud/core/issues/12915 and opens the door for potential other bugs...
Please test very carefully, this includes:
- Testing from OCS via cURL (as in #12915)
- Testing from OCS via browser (Open the "Von Dir geteilt" shares overview)
- WebDAV
- CalDAV
- CardDAV
Added oc:tags and oc:favorites in PROPFIND response.
It is possible to update them with PROPPATCH.
These properties are optional which means they need to be requested
explicitly
The existing method is deprecated and just a wrapper around the manager method. Since in the future other code paths might call this function instead we need to perform that check here.
Related to http://owncloud.org/security/advisory/?id=oc-sa-2014-020
This adds a "backend" type filter to the index REST route which is a pre-requisite for https://github.com/owncloud/core/issues/12620
For example when calling `index.php/settings/users/users?offset=0&limit=10&gid=&pattern=&backend=OC_User_Database` only users within the backend `OC_User_Database` would be shown. (requires sending a CSRF token as well)
Depends upon https://github.com/owncloud/core/pull/12711
This change will expose the user backend via the REST API which is a pre-requisite for https://github.com/owncloud/core/issues/12620.
For example:
````json
[{"name":"9707A09E-CA9A-4ABE-A66A-3F632F16C409","displayname":"Document Conversion User Account","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/9707A09E-CA9A-4ABE-A66A-3F632F16C409","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"ED86733E-745C-4E4D-90CB-278A9737DB3C","displayname":"Hacker","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/ED86733E-745C-4E4D-90CB-278A9737DB3C","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"71CDF45B-E125-450D-983C-D9192F36EC88","displayname":"admin","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/71CDF45B-E125-450D-983C-D9192F36EC88","lastLogin":0,"backend":"OCA\\user_ldap\\USER_LDAP"},{"name":"admin","displayname":"admin","groups":["admin"],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/admin","lastLogin":"1418057287","backend":"OC_User_Database"},{"name":"test","displayname":"test","groups":[],"subadmin":[],"quota":"default","storageLocation":"\/Users\/lreschke\/Programming\/core\/data\/test","lastLogin":0,"backend":"OC_User_Database"}]
```
* this needs to be properly fixed by a proper organisation of the base.php
* introduced fixDIInit() in AllConfig that moves the injection
of DatabaseConnection to a later point in time
* problems mostly because of the autoconfig setup
* keep old static methods - mapped to new ones and deprecated
* removed deleteApp, getUsers, getApps because they are unused
* make AllConfig unit tests more robust against not cleaned up environments
* introduce SystemConfig to avoid DI circle (used by database connection which is itself needed by AllConfig that itself contains the methods to access the config.php which then would need the database connection - did you get it? ;))
* use DI container and use that method in legacy code paths (for easier refactoring later)
* create and use getSystemConfig instead of query() in DI container
First step of a somewhat testable user management. - I know, the JSON returns are in an ugly format but the JS expects it that way. So let's keep it that way until we have time to fix the JS in the future.
The codepath that is executed when executing ownCloud via CLI is different than via browser. Specifically, the config is created by the user session already in `OC_Util::getInstanceId()` by a call to `setValue`. That said, this seems to be quite a bad side-effect, but for the sake of "not breaking whatever might break if we touch this" let's keep it that way for now.
When executing the autoconfig via `php -f index.php` the said session was not setup and thus no `config/config.php` file was created resulting in an installation error.
To reproduce this try to setup ownCloud via `php -f index.php` with and without that patch. (ensure to delete all existing configs before and don't access ownCloud with a browser in the meantime)
Fixes itself.
