search

ks888 / LambStatus

[Maintenance mode] Serverless Status Page System
https://lambstatus.github.io
Apache License 2.0
1.3k stars 119 forks source link

Upload of logo in admin returns 403 #95

Closed chris-scentregroup closed 6 years ago

chris-scentregroup commented 6 years ago

Trying to upload logo to settings in admin and a 403 is observed:

Request URL: https://abc123.cloudfront.net/api/settings/logos Request Method: OPTIONS

{"message":"Missing Authentication Token"}

ks888 commented 6 years ago

I guess the fix commented here fixes this issue, too.

Since v0.6.0, CORS settings for the APIs are removed because now APIs are served from the CloudFront as well as static files. Usually it has no problems. In this case, maybe the domain settings of the CloudFront was fixed by hand. As a result, static files are served from the custom domain but the js script tries to access the APIs using default cloudfront url (abcdefgh.cloudfront.net). Since CORS settings are removed, unfortunately that API access doesn't work anymore.

By the fix linked above, the js script starts to use the custom domain to access APIs and so the issue will be fixed.

chris-scentregroup commented 6 years ago

Performed an upgrade with the custom domain params per https://lambstatus.github.io/set-up-custom-domain but unfortunately the cf url is still being called direct.

ks888 commented 6 years ago

Ummm... the old cache may be there. Can you invalidate the objects in the CloudFront? https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

I guess invalidating the /settings.js object is enough, but please try /* if it doesn't work.

chris-scentregroup commented 6 years ago

Ok so I think that fixed the request URL but the error persists, here are some details:

Request URL: https://mycustom.domain/api/settings/logos Request Method: OPTIONS Status Code: 403 status: 403 x-amzn-errortype: MissingAuthenticationTokenException x-cache: Error from cloudfront

ks888 commented 6 years ago

The OPTIONS method is not supported so the error response is OK. Somehow the client still sends the OPTIONS request. Can you disable the browser cache or try other browser?

Or the protocol may be different (visit the page by http, but the API request uses https).

chris-scentregroup commented 6 years ago

This was testing in chrome with dev tools and disable browser cache. Alas, caching can certainly be a pain both on the cf and browser side. It worked on a fresh browser and some invalidation.

Thank you for the help as always! We'll consider this solved and may help other users in the future.