The network name and the network passphrase are never checked against each other

Open
  • Is something wrong?
#449 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
next.js, typescript
Domain
authentication, backend-api-design

Research direction

Start with src/lib/wallet.ts and .env.example, then trace how src/components/event-details.tsx and src/app/my-tickets/page.tsx use the network name. The issue proposes deriving the passphrase from a network map, validating overrides, and exposing the active network in the UI; related issues #305 and #306 add further scope. Done when mismatched network settings are caught before signing and the selected network is visible to users.

Written by the indexing model from the issue text.

Description

bug

Two independent env vars describe the same thing and nothing verifies they
agree:

  • NEXT_PUBLIC_STELLAR_NETWORK_PASSPHRASE → src/lib/wallet.ts:9-13, passed
    to Freighter on every signature (:46-49)
  • NEXT_PUBLIC_STELLAR_NETWORK → src/components/event-details.tsx:12 and
    src/app/my-tickets/page.tsx:30, used only to pick the explorer host

.env.example:4-6 relies on a comment to keep them in step ("Must match the
backend's STELLAR_NETWORK / the network Freighter is set to"), and
src/lib/wallet.ts:12 hardcodes the testnet passphrase as its dev fallback.
So a deployment that sets NEXT_PUBLIC_STELLAR_NETWORK=mainnet and forgets the
passphrase gets, in a non-production build, mainnet explorer links and testnet
signatures — and in production the resolveEnv guard fires, which is better but
only covers the missing case, not the mismatched one. Setting
mainnet with the testnet passphrase passes every check in the app.

The failure is ugly: Freighter signs for the wrong network, the backend submits
to the real one, and the transaction is rejected with a signature error that
points at nothing. Worse, the user has been shown a mainnet explorer link for an
event that doesn't exist there.

Fix: derive the passphrase from the network name instead of configuring it twice
— a NETWORK_PASSPHRASES map (testnet, public, futurenet) in
src/lib/wallet.ts, with the env var kept only as an override for custom/local
networks and validated against the map on startup. Then show the active network
in the UI (#305 asks for this) so a mismatch is visible before anyone signs, and
compare it against Freighter's own getNetwork() (#306).

Dominant language
TypeScript
Stars
0
Forks
42
Avg merge
7m
Merged PRs (30d)
16

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from StellarTickets/frontend

All issues in StellarTickets/frontend

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.