components
components copied to clipboard
serverless
Website component - Use access origin identity don't make bucket public
Description
I noticed some work was going into refactoring the website component, I was wondering if a feature request would be to modify the way that the bucket was accessed by the cloudfront distribution.
The current approch is to just make the entire bucket public and while this approch can work it doesn't allow the cloudfront distribtion to really have any control over security/ geoblocking or in the case of using subpaths allowing us to store publically accessable and private content in the same bucket.
Additional
Where is the code for the @serverless/website component? it doesn't seem to be in git and the code only seems to be accessable from the npm registry ?
Thanks for opening this up @thepont ... we're planning to add more options for the website bucket and what you are suggesting make sense. I'll keep it in mind while refactoring. Here's the website componnet repo:
https://github.com/serverless-components/website
I am already raised this ticket but haven't received any update https://github.com/serverless-components/website/issues/4
@eahefnawy do you have an EOA?
sorry for the delay here @hoang-innomizetech ... so much going on across the board. I'll try to get to it asap
@eahefnawy Thank you for your update. I hope you can release it before our launch time.
@hoang-innomizetech I'd love to hear about your use case and what you're building/launching. Feel free to reach out to me privately if you'd like (twitter/email)
Actually, right now we are using serverless components for hosting purposes. So we use a mono-repo that contains multiple apps that support multiple environments (I have raised #481 issue as well). We do a lot of static websites hosting and our clients complaint about public access, so we wanted to make sure we apply best practices and secure our client information. I was using Amplify for static hosting and it works well, but since our solution uses serverless framework so we don't want to mix it if the serverless component can do the same thing even better i.e. provision time
