Fix SPA error page behavior #165
Conversation
Switch the origin bucket configuration to static website hosting, leaving the configuration on the bucket side, without having to rely on a custom origin access identity. Fix getlift#163, getlift#164
|
This seems the right way forward to me 👍 And bonus, we get better support for static website hosting by supporting static site generation tools like Jekyll, Hugo, Gatsby, Nuxt/Next static target build, etc |
|
no need to handle 403 errors? |
|
@piolet I think 403 could not happen anymore because the bucket now has public read access |
|
Yes, with public access maybe. When I tested, my bucket had remained private, that's probably why I had to manage the 403 error |
ideally, this bonus could be applied to the server side website. I know I'm repeating myself, but it happens that sites generated with server and nuxt cohabit (a subdirectory of the main site for example #94 ) |
Yes that's exact ! |
| if (errorPath.startsWith("./") || errorPath.startsWith("../")) { | ||
| throw new ServerlessError( | ||
| `The 'errorPage' option of the '${this.id}' static website cannot start with './' or '../'. ` + | ||
| `(it cannot be a relative path).`, | ||
| "LIFT_INVALID_CONSTRUCT_CONFIGURATION" | ||
| ); | ||
| } | ||
| if (!errorPath.startsWith("/")) { | ||
| errorPath = `/${errorPath}`; | ||
| } |
There was a problem hiding this comment.
This bit was removed (and the corresponding test changed): this isn't necessary anymore with S3 doing the logic?
There was a problem hiding this comment.
Exactly, the correct path is resolved with or without a leading /
|
Just tested, worked well, thanks! That approach makes sense, I guess there's no way to disable the public S3 URL? (to avoid public duplicated content)
That's a very good point. Also I keep reading the code change but I don't understand why the OAI isn't deployed anymore. If you have an answer to that I'm interested. In any case, it's not important since the bucket would be public now (so the OAI isn't needed). |
an answer exists. Strangely enough, this is what was done before :) https://stackoverflow.com/questions/27636977/how-to-disable-amazon-s3-raw-endpoint-access |
If we want to let the bucket handle its website behavior, and not CF, I'm afraid not.
That's it yes, the OAI will no longer be needed since the bucket handles its static website access. |
|
👍 thanks for all the answers! |
Switch the origin bucket configuration to static website hosting,
leaving the configuration on the bucket side, without having to rely
on a custom origin access identity.
Fix #163, #164
An other possible solution would be to simply re-attach a custom origin access policy with the
s3::ListBucketpolicy, as explained in my comment in #163. The reason I did not implement this solution is to match lift goal on leveraging as much CDK default behaviors as possible.If this solution is preferred, I would be happy to update the PR 🙂