-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share links do not work for logged-in LDAP users with avatars #26517
Comments
My steps:
Works for me, cannot reproduce the issue. @Nilix007 the mentioned patch doesn't apply 100% on top of v9.1.1. Can you diff your file with the one from the 9.1.2RC2 release ? (https://github.com/owncloud/core/blob/v9.1.2RC2/lib/private/Files/Filesystem.php) So far it's not clear whether it's a patching issue or whether there is something else at play. |
It was more complicated than I thought at first, but I was able to reproduce the issue with an unpatched 9.1.2RC2 with our old database from 9.1.1. My steps to reproduce:
I am not sure where the difference is between your steps and mine. Maybe the fact that you are using an LDAP avatar and I set the avatar as an owncloud file via the webinterface? |
@Nilix007 thanks for the detailed steps. I tried just that and it still works fine. For the avatars I now used local OC files as avatars instead of LDAP avatars. Did you clear the browser cache + cookies before logging in as User A ? |
Downgrading to sev2-high as this is not a general issue (not reproducible) and need a specific env. |
Looking at your hotfix it seems to mean that somewhere there is previous code running that would setup the FS for the currently logged in user. But usually this should not happen for public links because it should switch to "incognito mode" early. I don't see any third party apps in your list so it is unlikely that a hook of some sorts would access the FS very early on this code path. Mind trying with 9.1.2 or 9.1.3RC1 and see whether the issue still exists ? 9.1.2 also contained other fixes related to avatars. |
The issue still exists with 9.1.2 and 9.1.3RC1. |
Thanks for checking. Need to find a way to reproduce this locally. |
Have you checked online whether other people were having similar issues ? You could try with 9.1.5 RC1 or 10.0 beta which contain a few more LDAP fixes. |
please try with 9.1.5. if the problem persists, please reopen. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Steps to reproduce
Expected behaviour
The user should see the shared file(s).
Actual behaviour
A blank page will be displayed.
Problem and hotfix
The problem is that the
setupFS
call inapps/dav/appinfo/v1/publicwebdav.php:75
fails becausesetupFS
has been called before (probably when the avatar was loaded). Afterwards, Owncloud is unable to find the mountpoint of the shared file because the mountpoints checked are from the logged-in user and not from the user who shared the file(s).The hotfix forces a tear down of the filesystem component so that the
setupFS
call succeeds.Server configuration
Operating system: Debian Jessie
Web server: Nginx 1.9.10
Database: Postgres 9.4
PHP version: 5.6.27
ownCloud version: 9.1.1 + patch from #26399
Updated from an older ownCloud or fresh install: Upgraded from 8.2 (via 9.0)
Where did you install ownCloud from: Owncloud deb repository
Signing status (ownCloud 9.0 and above): unknown :)
No errors have been found.
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: no, only local
Are you using encryption: no
Are you using an external user-backend, if yes which one: LDAP
LDAP configuration (delete this part if not used)
Client configuration
Browser: Firefox 49
Operating system: Debian Jessie
Logs
Web server error log
no log available
ownCloud log (data/owncloud.log)
Browser log
no log captured
The text was updated successfully, but these errors were encountered: