What is the best practice for storing API keys, secrets, environment variables etc for custom vue components?
My understanding is that anything you use in a section or element custom component is bundled and sent to the browser, so any secret is not secret anymore.
Plugins should have the ability to store public and private setting so that you can use the private setting when in the editor.
What is your use case?
But then the secrets will be visible on GitHub? That is a bad practice.
I am creating a plugin which requires me to send an API key every API request.
Rather than storing the secret on GitHub, the only thing I can think of which is secure is if I create an API which uses GitHub environment variables with terraform to replace the secret then I can retrieve securely.
Instead of putting the secret in the code you can have the secret as a property of your element. Then the user of your element will fill the parameter with the correct token in the weweb editor. In this way your secret is not stored in github but on weweb.
3 Likes
Are variables exposed client side? I am wondering if it is ok to pass a key into javascript by saving it to a variable.
Variables are bundled with your app, they couldn’t be used otherwise, that is transmitted to the browser.
Secret keys that you put in weweb’s plugins works differently, but any variable that you create in the editor is used client side.
1 Like
Hey,
what @dorilama is saying is true :). Everything you are doing in custom VueJS components is stored front side.
The only exception for that are plugins, which have a configuration. Part of it is public, another part is private. The private part is stored on our backend, and it’s available in the editor only. Then the API key is used only by the backend. This is how Airtable plugin is working for example.
This means that the requests are coming through our server, and that the plugin implies a server part. So this part is not available for external developer, as the backend part is not open.
If you had to do something with a private key, we advise you to do something similar, storing the key in your backend. If you want it to be configured by the user, then you need to develop your own API system so that the configuration is safely read/set in the editor (or other interface you own), but not accessible otherwise.
2 Likes
So what is the preffered way to use API that requires API key for every request? I’m talking about rest api based data collection in WeWeb
Do you have an API in mind? If your API was build for frontend consumption, you may have a special API Key for that.
If not (usually payment for ex), you need to setup a backend to proxy the call.
For example have an endpoint in your Xano who will call the other API with the API Key. This backend should have security and restriction about how to access the other API. Then weweb will call this backend.
I’m creating backend myself (in python), but my understanding is that putting api key directly in the configuration URL, might be a bad idea (it can be visible via developer tools in the browser). Is creating proxy server my only option here?
If you are doing a custom plugin, there are two parts of the configuration, one public, one private. The private part is sent only to the editor, and used mostly to enhance UX for settings (like getting your database scheme). Your logic should not depend on it.
Every other place will be available client side, so yes, this is not the correct place.
What is your exact use case?
My exact use case is to populate the frontend (table or collection list) with job offers from my backend (obviously it has to be done dynamically). I think it’s a very simple concept, normally with other frameworks like React I would have to pass the traffic through proxy, but I hoped it is solved in WeWeb somewhat differently, so it doesn’t require setting up additional server.
Sometimes WeWeb add a backend logic, but it’s possible only for our own plugin (Stripe or Airtable, for example).
If your backend logic depends on another service with an API Key, I advise you to have your backend handling authentication, and have a backend-backend exchange with the API Key (they are generally done for this, and not front-back. But it depends on your service)