There are three privacy states for a Val:
- 🌎 Public (anyone can view or run)
- 🔗 Unlisted (anyone with the name or link can view or run)
- 🔒 Private (only you can view or run)
All Vals default to private. You can publish a Val by clicking the 🔒 next to its name.
Publishing your Val as either Public or Unlisted makes it accessible via the Run API. Be careful about publishing a function val that has access to your environment variables — your environment variables will be used if others call that function via the Run API. Publishing a val makes it a public API.
You get to choose whether you share vals. They can be fully private, so only you can view, edit, and run them. Private vals are super useful for automating parts of your life or business. Or you can share vals publicly in the Val Town community, and let anyone learn from your creativity and expand on your work.
|Visible on the website
|Web & express endpoints
|Only if you have the link
|Requires token with each request
Exposing your vals to the internet
Public vals are great because they can be called from anywhere, anytime, instantly. They can also be called by anyone.
Since anyone can call your public endpoints, if they interact with some data that should only be changed by yourself, you will need to make sure that those endpoints check for some kind of secret that only you know.
Here’s an example of a val exposed using the HTTP Val, secured with an environment variable that only I know.
If I called it without supplying the environment variable, I’ll be denied access:
By supplying the environment variable in a header, I’m allowed access:
The rest of this article will focus on various common combinations of public and private vals that you’re likely to come across and how those interact with the permissions system.
Public code referencing private data
It is safe for a a public val to reference one of your private vals or one of your environment variables. Private vals are like environment variables in this way — others can see that they’re being used, but not their values.
For example, I created a private val,
example3. You won’t be able to see or
example3 but I can use it in
example4 which is public.
You can infer that the value of
"User" because of
how it’s used here. This is why you have to be careful about publishing vals
that reference private data. Typically you will reference private data in a way
that makes it impossible for others to infer what it is, like you would with an
environment variable credentials. Below I am passing my environment variables to an Upstash
Redis store. You can see that I’m using these environment variables and the output of this
computation, but you can’t get those values, nor can you rerun this script with
my environment variables.
Using another’s vals as a library
Using another’s val is like using a library from npm. The code runs entirely in your sandbox and they don’t get any access to your evaluation logs. In this way it is safe to pass other’s code your private data and environment variables.