OCIS web downloads fail #9560
Comments
|
Hi @micbar, hope you are well! Any idea why this might be happening? I could not find any documentation for upgrading from prerelease v5 to 5.0.5 or from 5 to 6. I am just assuming the upgrade path for the precompiled binaries is to swap out the binary, but if there are more steps I'd be grateful for a point in the right direction. It seems like "Cannot get user by claim" has something to do with my authentication method, but beyond that I'm lost. Here's the script I use to run OCIS on macos as well as the contents of my ocis.yaml |
|
We had a bug in the signed urls in 5.0.0 That can cause old presigned URLs before the upgrade to fail. Restart should fix everything.
Your asssuption is correct. When we need manual interaction, we would mention that in the release notes. |
Hi @micbar thanks for the reply. I have tried everything I can think of - restarting the server process, logging out and back in, changing the OCIS_SERVICE_ACCOUNT key etc, and I still have the issue. I am currently running 5.0.5. When I switch over to 6.0 binary, I end up with this issue plus #9538 |
|
I also tried 6.1.0. Using Web, I can upload and delete files, but not download them. Thumbnails don't work. I also can't replace the logo for some reason-it acts like it is replaced, but doesn't work. |
|
Something seems to be really broken. Seems that all access tokens and signatures are invalid. |
|
@ScharfViktor could you try reproduce that? |
My prior version was 5.0.0-rc.5. When I switch back to that binary, everything works fine. I haven't tried starting fresh but am hoping to avoid that... |
hm, I couldn't reproduce it. I tried to switch works fine to me. I can download files and view thumbnails |
Steps to reproduce would be to initialize storage with 5.0.0-rc5 and go from there |
also works if I upgrade ocis from ocis-5.0.0-rc.5-darwin-amd64 to cis-6.1.0-darwin-amd64 |
Strange. Well, I appreciate you guys looking into it. Unless there's anything else you can think of that would cause this to happen, I'm willing to try it. Otherwise I guess I will start over with a fresh install. |
|
I would not start with a fresh system. There seems to be a problem which I would suggest to find. |
Yes, I have a WOPI deployment in a Docker container in a VMware VM that we use for some things. For large files we have this other bare metal setup. I am using the shell script you see above and then a plist LaunchDaemon to keep it running. All in all it was very simple to set up-much easier than getting Docker working on a Mac. Below is my apache config, which hasn't changed. Were there any changes to ocis.yaml between 5.0.0-rc5 and 5.0.5? Or anything there or in the env vars I should play with? Thanks again. |
As a troubleshooting step I did the following:
Edit: Thumbnails are working, but when I try to download a file I get the web authentication dialog. So, this is happening on a fresh install as well. |
|
I experience similar issues with bare metal install under Linux. WebDAV seems unaffected I can also open a picture in the preview or use OnlyOffice via WOPI. External LDAP provider is used for user authentication. |
@ScharfViktor @micbar Echoing that for me the WebDAV connections are unaffected. Sync with apps works fine. Only web downloads result in the apache auth dialog. |
Hi @2403905 thanks for the pointer-I think the key to solving this is to identify what changed between 5.0.0-rc5 and 5.0.5 that would impact an apache reverse proxy configuration. As it stands, I can simply switch my binary back from 5.0.5 to rc5 and the issue is solved completely. Should I start trying other old versions to identify when the change occurred? My apache config is posted above. I did try restarting apache a few times. |
|
Something else I found: For this to work "PROXY_ENABLE_BASIC_AUTH" must be active else download in FireFox doesn't work either. Still trying to see if apache headers can adjusted for this to work, I also read some said using nginx instead works, I might try this as well, but I would prefer to keep using apache instead. |
Edit: I can confirm this behavior with Firefox. I haven't tried Chrome but assume it would be the same as Safari. Until this point I hadn't actually tried to log in with the HTTP auth dialog. When I do so, it does work in Safari too. However, in both Safari and Firefox, the "_" character is appended to the beginning and end of the downloaded filename. Very odd. I hope it is not the case that bare metal with apache is unsupported going forward. |
|
Finally got around testing with nginx instead of apache and could confirm nginx is working. in nginx does make this setup work, removing this header from nginx results in the same behavior as in apache. I assumed setting something like: Edit: |
|
@meveric Thank you for digging! That sounds like the first real "hunch" on this problem. I am interested to see if apache could be used to proxy ocis also. We ourselves have good experience with nginx and traefik. |
|
@micbar Please keep in mind, that in general it works fine using apache if using oCIS 5.x (under Linux at least) this seems entirely related to changes made in oCIS 6.x. (while I can't speak for MAC where this issue seems to show up even in 5.0.5 here). As well as some browsers work, using the basic_auth backend. |
I tried quite a few options in my Apache vhost config, but they did not work. This user suggested that ProxyPreserveHost On might work, but alas, not for me: The config I tried is as follows: |
Apache works perfectly on 5.0rc5, but not on subsequent versions. I forget where I found the config above-I believe it was contributed by another user in these forums. I did tweak it some, but never had any issues until moving to more recent versions. I hope the culprit can be identified, because for me at least, there is not much point to a bare metal version if there can't be a choice of web server (Apache being the more popular server by far). The next step for me is to give up and move to an intel NUC for our local fileserver, in which case I would be using a Docker deployment. |
|
@butonic any ideas? we had a sec fix in 5.0.0 in regards of signed urls. |
I have an OCIS deployment running on macos. I recently upgraded from a 5.0 alpha to 5.0.5 by replacing the binary and adding the needed OCIS_SERVICE_ACCOUNT and OCIS_SERVICE_ACCOUNT_SECRET env vars.
When I attempt to download a file from the web, I get a standard apache web authentication dialogue. Clicking "cancel" results in a 0b file. Very odd.
Below is the terminal output from the server. The relevant messages seem to be "proxy error signature match" "Could not get user by claim"
The text was updated successfully, but these errors were encountered: