Files
firezone/elixir
Jamil 54d91e2004 fix(portal): don't send reject_access for remaining flows (#10071)
This fixes a simple logic bug where we were mistakenly reacting to a
flow deletion event where flows still existed in the cache by sending
`reject_access`. This fixes that bug, and adds more comprehensive
logging to help diagnose issues like this more quickly in the future.

This PR also fixes the following issues found during the investigation:

- We were redundantly reacting to Token deletion in the channel pids.
This is unnecessary: we send a global socket disconnect from the Token
hook module instead.
- We had a bug that would crash the WAL consumer if a "global" token
(i.e. relay) was deleted or expired - these have no `account_id`.
- We now always use `min(max(all_conforming_polices_expiration),
token.expires_at)` when setting expiration on a new flow to minimize the
possibility for access churn.
- We now check to ensure the token and gateway are still undeleted when
re-authorizing a given flow. This prevents us from failing to send
`reject_access` when a token or gateway is deleted corresponding to a
flow, but the other entities would have granted access.


Related: https://firezone.statuspage.io/incidents/xrsm13tml3dh
Related: #10068 
Related: #9501
2025-08-01 00:03:00 +00:00
..

Firezone Elixir Development

Before reading this doc, make sure you've read through our CONTRIBUTING guide.

Getting Started

This is not an in depth guide for setting up all dependencies, but it should give you a starting point.

Prerequisites:

  • All prerequisites in the CONTRIBUTING guide
  • Install ASDF and all plugins/tools from .tool-version in the top level of the Firezone repo
  • Install pnpm

From the top level director of the Firezone repo start the Postgres container:

docker compose up -d postgres

Inside the /elixir directory run the following commands:

# Install dependencies
# --------------------
> mix deps.get

# Install npm packages and build assets
# -------------------------------------
> cd apps/web/
> mix setup

# Setup and seed the DB
# ---------------------
> cd ../..
> mix ecto.seed

# Start all of the portal Elixir apps:
# ------------------------------------
> iex -S mix

The web and api applications should now be running:

Stripe integration for local development

Prerequisites:

  • Stripe account
  • Stripe CLI

Steps:

  • Use static seeds to provision account ID that corresponds to staging setup on Stripe:

    STATIC_SEEDS=true mix do ecto.reset, ecto.seed
    
  • Start Stripe CLI webhook proxy:

    stripe listen --forward-to localhost:13001/integrations/stripe/webhooks
    
  • Start the Phoenix server with enabled billing from the elixir/ folder using a test mode token:

    cd elixir/
    BILLING_ENABLED=true STRIPE_SECRET_KEY="...copy from stripe dashboard..." STRIPE_WEBHOOK_SIGNING_SECRET="...copy from stripe cli tool.." mix phx.server
    

When updating the billing plan in stripe, use the Stripe Testing Docs for how to add test payment info

WorkOS integration for local development

Prerequisites:

  • WorkOS account

WorkOS is currently being used for JumpCloud directory sync integration. This allows JumpCloud users to use SCIM on the JumpCloud side, rather than having to give Firezone an admin JumpCloud API token.

Connecting WorkOS in dev mode for manual testing

If you are not planning to use the JumpCloud provider in your local development setup, then no additional setup is needed. However, if you need to use the JumpCloud provider locally, you will need to obtain an API Key and Client ID from the WorkOS Dashboard.

After obtaining WorkOS API credentials, you will need to make sure they are set in the environment ENVs when starting your local dev instance of Firezone. As an example:

WORKOS_API_KEY="..." WORKOS_CLIENT_ID="..." mix phx.server

Acceptance tests

You can disable headless mode for the browser by adding

@tag debug: true
feature ....