For me that sounds like a bug, but then I would see a topic about it here. So if my forum is the only one, then this must be an issue on my end.
Anyway.
My android users can’t see virtual keyboard if using rich text editor. When changed to markdown everything is fine. iPads and iPhones (Safari/PWA, DiscourseHub) are stuck in markdown, and can’t change to RTE.
This started two days ago, I reckon. My users have tendency to wait before they told me something is broken.
What else… self hosted, 2-container, on latest and upgraded every day and the newest is now 20 mins old at time of writing, safe-mode doesn’t help.
What is my next move? The console and possible errors aren’t an option on mobiles.
(index):1 Access to script at 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js' from origin 'https://foorumi.katiska.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
prosemirror-editor-opfbo6zd.digested.js:1 GET https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js net::ERR_FAILED 200 (OK)
d-editor.gjs:212 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://cdnfoorumi.katiska.eu/assets/br/prosemirror-editor-opfbo6zd.digested.js
Prosemirror is the RTEditor. But I cannot help further than sharing the error message I see.
Off topic: Thanks for the laugh about your “Kisses and animals” category (Sadly the English translations says ‘cats’ instead, so I will stick to the German one )
I don’t understand what I see here, but is the issue S3 and my settings there? If yes why it started recently? One symptom might be that since yesterday I couldn’t write any boards-notes anymore.
But if cors is a problem why only those are affected?
—
Why in the name of old and new gods AI used Küsse in that context
I don’t think there have been any recent Discourse changes to cause this. However, S3 does have a longstanding weirdness with CORS, which can cause CDNs to cache a version of the asset without any Access-Control-Allow-Origin header. And if it’s a bad-cache issue, that could explain why it only affects some of your users (likely based on their location).
IIRC - S3 will only serve the Access-Control-Allow-Origin header to requests which send an Origin header (i.e. those from a normal web browser). When Access-Control-Allow-Origin is omitted, it does not serve Vary: origin in its response. And so: if the first request for a given asset is sent from a non-web-browser-context (e.g. curl, or some web crawler), then the CDN can cache the version without the CORS header. Very annoying!
The DISCOURSE_CORS setting won’t help at all here. That’s only relevant to the application server, not S3.
On our hosting, we workaround this problem by configuring Cloudfront to add Access-Control-Allow-Origin: * to all responses. That makes sure that the weird S3 behaviour can’t cause a bad result to be cached.
Alternatively, you could configure Cloudfront to include the Origin request header in its cache key, which would then keep the non-cors responses separate from the cors responses.
Amazon have a bunch of documentation on CORS here. I had this link in my notes which apparently was a forum thread on exactly this issue… but it seems they deleted it
Yup exactly - required for a custom domain, and it also makes things cheaper (Cloudfront egress is cheaper than direct-s3 egress, if I remember correctly)
First, I removed all S3 references from the web_only.yml file. I then ran a rebuild and, just to be safe, rake posts:rebake. The issues disappeared, but the images were still being served via the CDN. I restored S3, and the problem came back.
I opened AWS and took a look at the distribution settings in CloudFront. I had at least one domain there that was over three years old, and its TLD had changed. I find it remarkable that anything worked at all. I updated the settings according to CloudFront’s recommendations and also set access-control-allow-origin: * at some point (which is silly, as it makes CORS pointless). However, as I understand it, that header was already being served through CloudFront.
Just to be safe, I ran another rebuild and tested it. It didn’t help.
Since it’s possible that the cache was acting up, I invalidated /assets/* and, just to be safe, /assets/br/* as well. I ran another rebuild, and this time the issue was fixed.
Another issue was fixed as well. I had been dealing with an Oops… (error 50x) issue after rebuilds since the summer. When I open safe mode and disable themes, I can access the admin area. I have to disable multiple TCs (around 20 or more) for the forum to come back to life. Then I can enable those components, and everything works again.
So, can we conclude that everything stemmed from issues with AWS CloudFront?
The Oops thing is quite surprising - I wouldn’t have expected that to be related to Cloudfront… But if it’s fixed now… great!
It just means “this asset is allowed to be used from a cross-site context”. You probably wouldn’t want this header on the actual forum HTTP responses. But for static assets, which don’t require authentication, and don’t include any private information, it’s totally fine. It’s exactly how the CORS system is supposed to be used - for servers to selectively control which responses should be available cross-site.
If you really wanted to, you could set Access-Control-Allow-Origin: my-forum.example.com. But then you’ll run into problems if you ever change your forum domain.
)
If I recall right it is needed to use own domain. Or something.