Closed SeanMerger closed 1 month ago
boxblinkracer
commented
2 years ago Hi
thanks for this oh. it could be that it uses the default flysystem ....this might lead to that can you send me your anonymous s3 configuration for shopware so that i can reproduce and fix it please?
thanks
SeanMerger
commented
2 years ago Hi @boxblinkracer,
thanks for looking into it! This is our configuration:
shopware: filesystem: private: type: "amazon-s3" config: bucket: "%env(S3_PRIVATE_BUCKET)%" endpoint: "%env(S3_PRIVATE_ENDPOINT)%" region: "%env(S3_REGION)%" root: "%env(S3_ROOT_PRIVATE)%" credentials: key: "%env(S3_KEY)%" secret: "%env(S3_SECRET)%" options: visibility: "private" public: type: "amazon-s3" url: "%env(S3_URL_PUBLIC)%" config: bucket: "%env(S3_PUBLIC_BUCKET)%" endpoint: "%env(S3_PUBLIC_ENDPOINT)%" region: "%env(S3_REGION)%" root: "%env(S3_ROOT_PUBLIC)%" credentials: key: "%env(S3_KEY)%" secret: "%env(S3_SECRET)%" options: visibility: "public" theme: type: "local" url: "%env(APP_URL)%/theme" config: root: "%kernel.project_dir%/public/theme" asset: type: "local" url: "%env(APP_URL)%/asset" config: root: "%kernel.project_dir%/public/asset" sitemap: type: "local" url: "%env(APP_URL)%/sitemap" config: root: "%kernel.project_dir%/public/sitemap"
boxblinkracer
commented
2 years ago Hi @SeanMerger
I've just improved this feature to support custom filesystem adapters but I'm still wondering if your S3 setup would allow access to the public folder where its now always located
would you mind giving this PR a try? just small changes...would help a lot :)
boxblinkracer
commented
2 years ago Hi @SeanMerger
alright, I have news. so the current download implementation is based on the Shophware "public" filesystem adapter. this stores into the public DocRoot so that the file is accessable. People who use this for HA setups with multiple shop instances and a shared NFS storage, rely on this implementation. otherwise the file might not be available through all shop instances.
in your case we have an external cloud storage system. it would actually need write permissions, then the download would successfull work. unfortunately it won't work, even with the public S3 url that you provide, because it's not delivered through the Media Service at all...it's just a plain file in the public DocRoot which wouldn't (again) exist in your app instance DocRoot.
Maybe you have an idea, but I don't really know a good solution at the moment. I could add a warning to the CLI command in case the "public" adapter is not a file system adapter, or just leave it as it is.
the solution for you would be to download the file manually into your required DocRoots and make it accessible with your shop domain (Apple requires this) heres the shared Mollie file for all merchants: https://www.mollie.com/.well-known/apple-developer-merchantid-domain-association
besides adding some information warnings and texts, I have no good idea to make it work for all merchants and still support your case. i know it's not a real edge case, but compared to the number of merchants it is.
so please let me know if you have an idea maybe, because I really want to help you :)
PS: one crazy idea would be to create a Controller action for the URL where it would be possible to dynamically fetch or even decorate the Mollie apple pay domain verification file.....but mhm...i dont know
BlackScorp
commented
1 month ago iam going to close this old ticket
Hi,
when trying to activate (installation works) v 2.2.0 in an environment, where the filesystem is outsourced to S3 (not sure about others), Mollie tries to write the apple-developer-merchantid-domain-association file to S3 in the public/.well-known folder. This doesn't work (+ it would also verify the AWS domain and not the shop domain).