Access denied getting protocol page

[bhackett1024]

Visiting https://replay.io/protocol returns an XML-ey access denied page.

[bhackett1024]

https://replay.io/driver as well

[hbenl]

@jazzdan These URLs are configured as Next.js rewrites to https://dc3tvimjwmdjm.cloudfront.net/protocol and https://dc3tvimjwmdjm.cloudfront.net/driver and those URLs return the same error denied page. I guess this is due to the recent permission changes.

[jazzdan]

Well, crucially these will stop working once we switch to the new site anyways which will no longer be backed by next.js, so we should probably figure out something else to do here.

[bhackett1024]

Isn't this purely an AWS issue? The cloudfront links are going straight to AWS and it is returning the access denied error.

[jazzdan]

I just mean that the new site uses webflow which, afaict, doesn't support reverse proxying. Which I think means that a URL like replay.io/protocol wouldn't work?

The fact that https://dc3tvimjwmdjm.cloudfront.net/protocol doesn't work is a separate problem that we might have to fix too

[jazzdan]

So that cloudfront distribution points to this S3 bucket. Inside of that S3 bucket is an object under the key protocol/index.html, which if you navigate to in your browser, totally works https://recordreplay-website.s3.us-east-2.amazonaws.com/protocol/index.html. So it doesn't seem like the problem is that cloudfront doesn't have access to that object because everyone has access to that object. Hmm.

[jazzdan]

Interestingly https://dc3tvimjwmdjm.cloudfront.net/protocol/index.html works but https://dc3tvimjwmdjm.cloudfront.net/protocol doesn't.

[jazzdan]

Also: http://recordreplay-website.s3-website.us-east-2.amazonaws.com/protocol/ renders index.html correctly, but https://dc3tvimjwmdjm.cloudfront.net/protocol doesn't. 🤔

[jazzdan]

This may be the result of something I accidentally changed when I imported the cloudfront distribution in to pulumi. I'm trying some stuff now.

[jazzdan]

@hbenl @bhackett1024 should be fixed now, PR incoming!

[jazzdan]

But my comment about the website stands, might want to get on VC to talk about it.

[jazzdan]

https://github.com/RecordReplay/backend/pull/2976

[hbenl]

Well, crucially these will stop working once we switch to the new site anyways which will no longer be backed by next.js, so we should probably figure out something else to do here.

https://static.replay.io/protocol/ and https://static.replay.io/driver/ work (and will keep working when the new site goes live), so couldn't we just link to those URLs?

[jazzdan]

@hbenl yes that would work

[ryanjduffy]

Wonder if we'd be better served with these rules implemented at the load balancer so we wouldn't be constrained by the capabilities of vercel and/or webflow.

[jazzdan]

Yeah putting a load balancer in front of webflow is an option, though @gideonred mentioned that it can cause problems with webflow if you mess with the request too much.

[gideonred]

Yeah putting a load balancer in front of webflow is an option, though @gideonred mentioned that it can cause problems with webflow if you mess with the request too much.

3 years ago we tried to put a webflow site behind Cloudflare to introduce more security headers because if you run any security header checker against a webflow (or squarespace) hosted website it comes back with a pretty terrible score. If I recall correctly we had two issues: 1) Webflow has all kinds of interactive javascript on your hosted site for the site owner to edit the site while viewing it. All these scripts broke. 2) Webflow introduces "Powered by Webflow" text visible on the page when it detects that it's not being served directly from Webflow.

This is based on things many years ago. I'd probably look at taking another pass at doing it.