mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Issues with BookStack not communicating with s3 compatible service over proxy #1000
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ssddanbrown on GitHub (Jan 20, 2019).
See https://github.com/BookStackApp/BookStack/issues/1192#issuecomment-455312051
@armouredking commented on GitHub (Jan 21, 2019):
Things I think we all agree on:
ADDR:PORT for the ENDPOINT and STORAGE_URL parameters works (no proxy). Bookstack and Minio behave as expected.
DOMAIN.NAME for the ENDPOINT and STORAGE_URL parameters does not work. Problems are shown in detail in #1192, but the exact nature of the fault is unknown. I suspect Bookstack is not getting a reply it understands / likes / accepts / acknowledges over the proxy from Minio when performing file operations and lookups. The only proxy in this case is with Minio, the APP_URL field is not defined. Defining the APP_URL field and putting Bookstack behind a proxy as well does not change any behaviour related to this issue though. Bookstack and Minio, separately, work fine behind the proxy. It's only when attempting to communicate via proxy between them that issues occur.
New stuff:
Trying to cheat: ADDR:PORT for ENDPOINT and DOMAIN.NAME for STORAGE_URL. This generates errors, I think due to the way these fields are employed currently; I was trying to get Bookstack to communicate with Minio via the backend only (since this works) but still create the links on the public face as if proxied (we wanna cheat). This is because we know that we can access the files on Minio with either ADDR:PORT or DOMAIN.NAME externally. I think as a workaround this is probably the simplest solution.
Obviously the best thing is to figure out what is generating this "promise" error when talking via proxy to Minio. I'm just kinda at the end of what I know how to do to figure out what is causing it or to give me a new / different error.
@armouredking commented on GitHub (Feb 7, 2019):
Hey, @ssddanbrown, an update:
I went ahead and restarted this today with fresh pulls from Docker Hub. I was working with Rocket.Chat and noticed it had an oddity with setup (if you defined the bucket url in Rocket.Chat with the bucket -as recommend on their docs- it would result in creating a second folder, so like domain.name/bucket/bucket). Thought maybe I could so some more similar testing with the pathing on Bookstack only to get started and... it's working. The env file is the only item touched:
I then went over to the production instance and changed it as well, and moved the files from bookstack folders to minio's buckets keeping all pathing and such and... everything is still working. Additionally, I was able to upload and delete images. One minor oddity that I think is working as intended, was that avatars are not shared. So like if my admin account assigns an avatar to someone's user account, the user cannot see the avatar when they go to change it. Edit Profile -> Select Image will just show up blank with no pictures. Viewing from the admin account I can however see the avatars I uploaded; but only those uploaded as an admin (I could not see a file uploaded by a user account either). Shouldn't admin users be able to see all user account avatars uploaded? Because if they can't how can you administrate if someone uploads an avatar they shouldn't?
I did not need to define the ports. Was something else besides what we tested with the env and filesystems files changed? Can you test this with a proxy as well and verify working now?
@armouredking commented on GitHub (Feb 8, 2019):
On topic, I tried a few different other scenarios just to see what does / doesn't work. Defining the ENDPOINT as https://domain.name/bookstack does not change anything. Not sure if the logic just truncates or simply doesn't care; it works either way for me. Defining the STORAGE_URL without the path, so just as https://domain.name/ leads to breakage since the path is not included in the urls, even if you did add it to ENDPOINT above.
Off topic, but on the avatar thing, here's what I've found via experimentation:
Admin sets user avatar. User cannot see this avatar in the image selector screen, has to upload their own. If they remove their own avatar, the admin set avatar is reassigned. The admin cannot see what users upload either though. I'm assuming this is a user permissions isolation?
@ssddanbrown commented on GitHub (Mar 3, 2019):
Hi @armouredking,
Sorry for my really late reply. I've been meaning to response once I've verified everything on my own reverse proxy + minio setup but I just haven't had the time to get my head around setting up the container network.
It's great that you got things working though. I'll close this off since things are now okay on your side.
In regards to the user avatar images, That logic does seem incorrect. Think that's just an oversight on my part. I'll open up a new issue to amend that so images shown are specific to the profile being edited.