[Feature Request] server-only environment variables should not be sent to client
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 48/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start by tracing how /api/public-env selects variables and how the @public, @dynamic, and @sensitive markers are defined and applied. The issue does not name implementation files or tests, so locate the endpoint and its coverage first. Done means only variables explicitly marked for client exposure are returned, with build-time and runtime behavior covered.
Written by the indexing model from the issue text.
Description
Description
documentation say /api/public-env expose only environment variables marked with @public and @dynamic
But it actually exposing some serve-side only environment variables marked with @sensitive=false and @dynamic. This might be a security risk.
<script>
globalThis.__varlockPublicDynamicEnv={
"FF_ENABLE_DARK_MODE":false,
"BETTER_AUTH_URL":"http://localhost:3000",
"TURNSTILE_SITE_KEY":"1x00000000000000000000AA"};
...
globalThis.__varlockPublicDynamicEnvEndpoint="/api/public-env";
</script>
Motivation
I want only expose some environment variables that are changeable at runtime (@public and @dynamic)
don't want to expose all non-sensitive server-only variables.
Proposed Solution
please provide 3 dimensions of markers for env variables
- client-side: true/false (whether they should exposed to browser - either at build-time or run-time)
- dynamic: true/false (build-time inject vs run-time inject)
- sensitive: true/false (secrets or non-secrets)
Alternatives
No response
Additional Information
No response
- Dominant language
- TypeScript
- Stars
- 4.9k
- Forks
- 140
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 35
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dmno-dev/varlock
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
dmno-dev/varlock#1279 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
dmno-dev/varlock#1100 · 3 comments ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
dmno-dev/varlock#1278 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
dmno-dev/varlock#1275 · 1 comment ·
Maintainers usually reply within 1 day
-
core:varlock RFC
Difficulty 5/5 Over a week Newbie friendliness 28/100
dmno-dev/varlock#1258 · 1 comment ·
Maintainers usually reply within 1 day
All issues in dmno-dev/varlock
Similar issues
-
documentation good first issue roadmap
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
resend/react-email#3876 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
siyuan-note/siyuan#21324 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
himynameisdave/bsky-profanity-counter#59 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100