The CSP nonce is based on the CSRF token. This token does not change,
unless you log in (or out). In case of the session data being lost,
e.g. because php gets rid of old sessions, a new CSRF token is gen-
erated. While this is fine in theory, it actually caused some annoying
problems where the browser restored a tab and Nextcloud js was blocked
due to an outdated nonce.
The main problem here is that, while processing the request, we write
out security headers relatively early. At that point the CSRF token
is known/generated and transformed into a CSP nonce. During this request,
however, we also log the user in because the session information was
lost. At that point we also refresh the CSRF token, which eventually
causes the browser to block any scripts as the nonce in the header
does not match the one which is used to include scripts.
This patch adds a flag to indicate whether the CSRF token should be
refreshed or not. It is assumed that refreshing is only necessary
if we want to re-generate the session id too. To my knowledge, this
case only happens on fresh logins, not when we recover from a deleted
session file.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
In some not yet completely determined configurations, the following error could occur while writing a file:
Error: Call to a member function getUsers() on null
/var/www/nextcloud/lib/private/Share20/Manager.php - line 1277: OC\Share20\DefaultShareProvider->getAccessList(Array, true)
/var/www/nextcloud/lib/private/Share20/ShareHelper.php - line 51: OC\Share20\Manager->getAccessList(Object(OC\Files\Node\Folder), true, true)
/var/www/nextcloud/apps/activity/lib/FilesHooks.php - line 616: OC\Share20\ShareHelper->getPathsForAccessList(Object(OC\Files\Node\File))
/var/www/nextcloud/apps/activity/lib/FilesHooks.php - line 196: OCA\Activity\FilesHooks->getUserPathsFromPath('/path/to/file', 'user')
/var/www/nextcloud/apps/activity/lib/FilesHooks.php - line 157: OCA\Activity\FilesHooks->addNotificationsForFileAction('/path/to/file', 'file_changed', 'changed_self', 'changed_by')
/var/www/nextcloud/apps/activity/lib/FilesHooksStatic.php - line 55: OCA\Activity\FilesHooks->fileUpdate('/path/to/file')
/var/www/nextcloud/lib/private/legacy/hook.php - line 106: OCA\Activity\FilesHooksStatic fileUpdate(Array)
/var/www/nextcloud/lib/private/Files/View.php - line 1245: OC_Hook emit('OC_Filesystem', 'post_update', Array)
/var/www/nextcloud/lib/private/Files/View.php - line 1173: OC\Files\View->runHooks(Array, '/path/to/file', true)
/var/www/nextcloud/lib/private/Files/View.php - line 679: OC\Files\View->basicOperation('file_put_conten...', '/path/to/file', Array, '<?xml version="...')
/var/www/nextcloud/lib/private/Files/Node/File.php - line 64: OC\Files\View->file_put_contents('/path/to/file', '<?xml version="...')
[...]
Signed-off-by: Jan-Philipp Litza <janphilipp@litza.de>
* 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>
PHP's json_encode only accept proper UTF-8 strings, loop over all
elements to ensure that they are properly UTF-8 compliant or convert
them manually.
Without this somebody passing an invalid User Agent may make json_encode
return false which will get logged as empty newline.
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
Nextcloud bot
Roeland Jago Douma
Morris Jobke
Joas Schilling
Christoph Wurst
Roeland Jago Douma
Lukas Reschke
Jan-Philipp Litza
Bjoern Schiessle
Maxence Lange