Rethinking secret request values - New s for secrets.

[alexiglesias93]

Intro

Currently REST requests have a quite controversial setting: Execute on server?.
Toggling this setting on does what is says, it executes the request on Wized's servers instead of on the user's browser.

This has one sole use case: preventing exposing private API keys (or any other private value) on the client.
Users have to use this setting in conjunction with the Value is a secret? setting, where they explicitly define the values that are not supposed to be publicly exposed:

Defining a value as a secret will convert it from dynamic to static in order to store it in our database.
If all is set up correctly, Wized will remove this private value from the published config, and when executing the request it will send it to our servers where we have safe access to the private value.

The problem

This approach works fine (mostly) when users set it up correctly, but it has a couple big downsides.

Confusing for users

I've seen many cases where users think that if they are handling an access token (or similar), they have to set the Authorization header to be a secret. After all, it makes total sense that somebody can reach to that conclusion:

1. I have logged in the user and retrieved an access_token.
2. This access_token is private from the user. Only the user has it.
3. Hence I must mark Value is a secret because the access_token is private.

But this is a wrong statement.
Any value that is retrieved on the client after, for example, signing in, is completely exposed on the browser. The user has access to it because he signed in. No one else has access to it, only the user, but still, it is exposed on the browser.

A true secret value is a value that nobody must see. Not even users after signing in. For example: a Webflow CMS API token.

Lack of security, hard to reuse

Currently secret values end up hardcoded in the request config. This means that anybody accessing the project (like an Editor) could see those keys.
On top of that, the moment that users need to update the values, they will have to do it manually in each request that uses them.

The proposal

I suggest we get rid of the Execute on server? & Value is a secret? options.
Instead, we create a new Secrets store in the Page Data panel.

Creating a secret will work exactly as creating a Variable:

And it will be exposed in the code editor via the s key:

The main difference from regular variables relies on how Wized will treat it:

• When a secret is defined, it will be stored in Wized's Database. It will be never exposed in the published config.
• The s key will only be accessible from inside a Request config.
• If a secret is used in any request field, that request will automatically be executed in Wized's server instead of on the client.

With this, we solve all the current problems:

• No more confusions for users. A secret will never end up in the browser. Users will never have to explicitly define a request to run on the server. Wized will handle it automatically for them, only when necessary.
• More security: we will never display again a secret value after creating it for the first time. Users will be able to update it, but never read it.
• Easier reusability and maintenance. Define the secret in one place, consume it everywhere.

[Manki32]

One word: YES!

[theflowagency]

This sounds great. One question for clarification: will we continue as normal to store access tokens on the client via cookies in order to send on subsequent requests that require Auth? It would still need to be made clear to the Wized Dev to NOT make this a Secret, right? Or will the Wized Dev have the option to store the generated access token as a Secret value anyway i.e. is there still a choice for this use case?

[alexiglesias93]

Use of access tokens won't change, the workflow of storing an access token to a cookie remains completely valid.
This change only affects to use cases where the API token must never end up in the browser under any circumstances, like a private API key.

[theflowagency]

Thanks for verifying that for me / us, Alex.

[andresmmax]

This is definitely and great approach! Now will dynamic data work using this new approach? Use case lets say I have set a request to pull in Mailchimp marketing data, but each user/client has their own API key that needs to be protected or would at that point not make sense to keep it hidden since the user login in is the only one that can see it?

[alexiglesias93]

@andresmmax I assume that each user's API key comes from the server after loging in? In that case it would be the same scenario as the access tokens. They are private to the user but they can be exposed on the user's browser without any problem.

[MatzeBothe]

@alexiglesias93 this feature is highly needed! The lack of a feature to store secrets in Embed 2.0 prevents us from building our new projects in Embed 2.0.

[alexiglesias93]

The Secrets functionality is now fully working in our staging environment (https://sa.wized.com), I encourage everyone to give it a try!
Here's an in-depth what, why, how explanation of Secrets:

https://www.loom.com/share/ba9c529db2724db2950ac93caee823f8?sid=df274b86-e451-46ae-ae81-63eee933e055

[theflowagency]

A small announcement with a huge impact! I know many of us have been waiting for this one so I'm happy to jump in and test + report back anything I see here.

[theflowagency]

After a quick test with a brand new Webflow project with a new API Key + a new (staging) Wized project + a Request to a Webflow CMS Collection, I can confirm that it is all working for me. No sign of an exposed key in the console either👍

[alexiglesias93]

Closing this as it was shipped early this week.