PhoenixKitWeb.Plugs.WebsiteAccess (phoenix_kit v2.22.0)

Copy Markdown View Source

The website-access features, in the browser pipeline, in this order:

  1. an allowed address passes everything below;
  2. redirect to production — a public GET/HEAD from a visitor who is not logged in and not on an admin path is sent to the same path on the production site (bounce the public first: only people who may stay ever see a prompt);
  3. the password gate — no unlocked session means the gate page and nothing else (the gate's own route and the site's assets pass, so the page can render and be submitted);
  4. maintenance — what it did before this plug existed;
  5. the visitor notice is injected into the HTML response, the way core injects its websocket fix.

Each step is a no-op when its feature is off. The gate stands in the browser pipeline: it protects the site's pages; files a host serves outside that pipeline are not behind it.

Summary

Functions

allowed_session_key()

The session key an allowed address is remembered under (for LiveView mounts).

call(conn, opts)
gate_path()

The gate page's path — the one route the gate itself must let through.

init(opts)
pass(conn)

Whether conn may pass the gate: its session is unlocked, or it belongs to a logged-in user and logged-in users pass (then the session is stamped as unlocked, so the next request costs nothing).

Functions

allowed_session_key()

The session key an allowed address is remembered under (for LiveView mounts).

call(conn, opts)

gate_path()

The gate page's path — the one route the gate itself must let through.

init(opts)

pass(conn)

@spec pass(Plug.Conn.t()) :: {:ok, Plug.Conn.t()} | :locked

Whether conn may pass the gate: its session is unlocked, or it belongs to a logged-in user and logged-in users pass (then the session is stamped as unlocked, so the next request costs nothing).