-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Add the ability to load site specific or custom configurations #1639
Comments
Hi @vinhtrinh, thanks for your interest in the PWA-Kit. I have a few comments about your suggestion and ideas what we might be able to do to provide you some assistance. First, with regards to this code :
I want to say that, you've high lighted something that isn't currently supported, that is placing secrets in the config. The reason being is the react rendering pipeline on the server simple serializes the config without prejudice. Meaning that any secretes you have in environment variables will most likely end up on the client (bad). This shouldn't be too hard to add support for. For example we could treat any key in the config that ends with We are open to contributions being an open source project, if that is something you want to look into. I'll bring it up to the team and see if its something we can get on our roadmap. Moving on, looking at you other suggestion about site specific configurations being build in:
Unfortunately in javascript land we do not know what the current site is unless we were to look at the window.location, but then again that would only work on the browser. Fortunately this is pretty easy to solve in your application as the config files themselves are javascript. You can simply import you site specific config into the main config file and place it under the site property. So it's not going to be something that we'll be adding support for.
Within you react app you can use the multisite hook to get you site information:
I hope this helped. |
Hi @bendvc, thank you for the detailed response. If we want to use naming convention to exclude secret or private configs, I would suggest that use the It would be great if we can supports both because the custom configuration has it own benefits in real projects.
About the The main purpose of this method is provide a standard configuration structure as a reference to avoid unexpected behavior. Site configuration (or any other custom configuration files) should be placed in a sub-directory to avoid environment name conflicts. E.g., For Example: the issue with the default Retail React App setup is: if developer create a new environment in the MRT named |
Hey @vinhtrinh There are a lot of good ideas so I'll try to keep the message short. When it comes to supportive private secrets we most likely won't support using a configuration file as a valid place to house secrets. The reason being is that it opens up the number of attack vectors to have that sensitive data stolen, you would have your repository and the aws environment. For that reason we are currently looking into ways to support secret values where they would be only stored as environment variables. With regards to requesting a stricter more organized configuration schema, we can take that on board. The beauty of use having javascript support for our configurations is that you can require files from any custom structure that you choose to create. Continuing, we do already support environment specific configurations as shown in this doc. Selective configuration.. I'm not sure I understand, can you give me an example/use case of this feature? With respect to the example of having an environment named "sites", probably rare, but valid. I suggest that you create a bug issue for that so we can track and look into it. |
Is your feature request related to a problem? Please describe.
When implementing PWA apps, we need a secure location to store and retrieve site-specific and custom configurations for third-party integrations. These configurations should not be exposed to the client-side. Examples include: site preferences, third-party service API keys, etc.
Describe the solution you'd like
The custom configurations should align seamlessly with the existing application configurations functionalities.
Additional context
Some simple examples of usage:
The text was updated successfully, but these errors were encountered: