Agent skill

Phoenix Authorization Patterns

by j-morgan6 in j-morgan6/elixir-phoenix-guide

A skill your agent uses when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers.

MITAuto-check passedBackend & APIs

Install Phoenix Authorization Patterns

skills CLI
$ npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-authorization-patterns -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install j-morgan6/elixir-phoenix-guide phoenix-authorization-patterns --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/j-morgan6/elixir-phoenix-guide.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/phoenix-authorization-patterns .claude/skills/phoenix-authorization-patterns && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
phoenix-authorization-patterns
GitHub stars
166
Token cost
~2.1k tokens
SKILL.md length
230 words
Files
1
Skills in repo
19
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers.

  • Works in 6 steps: Always authorize on the server in event… → Verify resource ownership by comparing… → Use policy modules for complex… → …
  • Deciding who may do what — ownership checks
  • SKILL.md covers RULES — Follow these with no…, Server-Side Authorization in…, Owner-Only Pattern and Scoped Queries in Contexts, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Phoenix Authorization Patterns is an agent skill from j-morgan6/elixir-phoenix-guide. Use when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers.

Its SKILL.md is about 2.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Authorization and RBAC and LLM observability. The licence is MIT.

When your agent uses it

  • Deciding who may do what — ownership checks
  • Role-based access in LiveViews and controllers

Example prompts

  • “/phoenix-authorization-patterns”

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Always authorize on the server in event handlers — UI-only checks (hiding buttons) are not security; always verify in handle_event/3
  2. Verify resource ownership by comparing current_scope.user.id against the resource's user_id — never trust client-sent user IDs
  3. Use policy modules for complex authorization — don't inline permission checks in LiveViews or controllers
  4. Add data-confirm attribute for destructive UI actions — client-side confirmation before server round-trip
  5. Test both authorized and unauthorized paths — every handle_event that mutates data needs an authz test proving unauthorized access is…
  6. Scope queries to the current user in contexts — where(user_id: ^user_id) prevents IDOR vulnerabilities

What it can do on your machine

Read from SKILL.md and the folder at commit cdfddac. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are elixir).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Phoenix Authorization Patterns loads about 2.1k tokens when it runs. Until then it costs about 41 tokens; SKILL.md has 230 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~41
When it runs · the whole SKILL.md, loaded when a task matches
~2.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from j-morgan6/elixir-phoenix-guide at commit cdfddac, republished under its MIT licence (© j-morgan6). 230 words, ~2,145 tokens.

Download SKILL.mdSave it as .claude/skills/phoenix-authorization-patterns/SKILL.md (or your agent's skills folder).
name
phoenix-authorization-patterns
description
Use when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers.
file_patterns
**/*_live.ex, **/*_live/*.ex, **/controllers/**/*.ex
auto_suggest
true

Phoenix Authorization Patterns

RULES — Follow these with no exceptions

  1. Always authorize on the server in event handlers — UI-only checks (hiding buttons) are not security; always verify in handle_event/3
  2. Verify resource ownership by comparing current_scope.user.id against the resource's user_id — never trust client-sent user IDs
  3. Use policy modules for complex authorization — don't inline permission checks in LiveViews or controllers
  4. Add data-confirm attribute for destructive UI actions — client-side confirmation before server round-trip
  5. Test both authorized and unauthorized paths — every handle_event that mutates data needs an authz test proving unauthorized access is rejected
  6. Scope queries to the current user in contexts — where(user_id: ^user_id) prevents IDOR vulnerabilities

Server-Side Authorization in LiveViews

UI checks prevent accidental clicks. Server checks prevent attacks. You need both.

elixir
defmodule MyAppWeb.PostLive.Show do
  use MyAppWeb, :live_view

  @impl true
  def mount(%{"id" => id}, _session, socket) do
    post = Blog.get_post!(id)
    {:ok, assign(socket, :post, post)}
  end

  @impl true
  def render(assigns) do
    ~H"""
    <h1><%= @post.title %></h1>

    <%!-- UI check — hide button if not owner --%>
    <%= if @current_scope.user.id == @post.user_id do %>
      <.button phx-click="delete" data-confirm="Are you sure?">
        Delete
      </.button>
    <% end %>
    """
  end

  # Server check — ALWAYS verify ownership
  @impl true
  def handle_event("delete", _params, socket) do
    post = socket.assigns.post

    if socket.assigns.current_scope.user.id == post.user_id do
      {:ok, _} = Blog.delete_post(post)
      {:noreply, push_navigate(socket, to: ~p"/posts")}
    else
      {:noreply, put_flash(socket, :error, "Not authorized")}
    end
  end
end

Owner-Only Pattern

The simplest and most common authorization pattern. Extract it for reuse.

elixir
defmodule MyAppWeb.PostLive.Edit do
  use MyAppWeb, :live_view

  @impl true
  def mount(%{"id" => id}, _session, socket) do
    post = Blog.get_post!(id)

    if authorized?(socket, post) do
      changeset = Blog.change_post(post)
      {:ok, assign(socket, post: post, form: to_form(changeset))}
    else
      {:ok,
       socket
       |> put_flash(:error, "Not authorized")
       |> push_navigate(to: ~p"/posts")}
    end
  end

  @impl true
  def handle_event("save", %{"post" => params}, socket) do
    post = socket.assigns.post

    if authorized?(socket, post) do
      case Blog.update_post(post, params) do
        {:ok, post} ->
          {:noreply, push_navigate(socket, to: ~p"/posts/#{post}")}
        {:error, changeset} ->
          {:noreply, assign(socket, :form, to_form(changeset))}
      end
    else
      {:noreply, put_flash(socket, :error, "Not authorized")}
    end
  end

  defp authorized?(socket, resource) do
    socket.assigns.current_scope.user.id == resource.user_id
  end
end

Scoped Queries in Contexts

The strongest authorization pattern: queries only return data the user owns. No separate check needed.

elixir
defmodule MyApp.Blog do
  import Ecto.Query

  # Scoped — only returns posts owned by this user
  def list_user_posts(%Scope{user: user}) do
    Post
    |> where(user_id: ^user.id)
    |> order_by(desc: :inserted_at)
    |> Repo.all()
  end

  # Scoped get — returns nil if not owned by user
  def get_user_post(%Scope{user: user}, id) do
    Post
    |> where(user_id: ^user.id)
    |> Repo.get(id)
  end

  # Scoped update — only updates if owned
  def update_user_post(%Scope{user: user}, %Post{} = post, attrs) do
    if post.user_id == user.id do
      post
      |> Post.changeset(attrs)
      |> Repo.update()
    else
      {:error, :unauthorized}
    end
  end

  # Scoped delete — only deletes if owned
  def delete_user_post(%Scope{user: user}, %Post{} = post) do
    if post.user_id == user.id do
      Repo.delete(post)
    else
      {:error, :unauthorized}
    end
  end
end
Using Scoped Contexts in LiveViews
elixir
@impl true
def mount(_params, _session, socket) do
  scope = socket.assigns.current_scope
  posts = Blog.list_user_posts(scope)
  {:ok, assign(socket, :posts, posts)}
end

@impl true
def handle_event("delete", %{"id" => id}, socket) do
  scope = socket.assigns.current_scope

  # get_user_post/2 is scoped — it returns nil for posts that don't exist
  # OR that exist but aren't owned by this user, so nil must be handled
  # before calling delete_user_post/2
  case Blog.get_user_post(scope, id) do
    nil ->
      {:noreply, put_flash(socket, :error, "Not found")}

    post ->
      case Blog.delete_user_post(scope, post) do
        {:ok, _} -> {:noreply, update(socket, :posts, &Enum.reject(&1, fn p -> p.id == post.id end))}
        {:error, :unauthorized} -> {:noreply, put_flash(socket, :error, "Not authorized")}
      end
  end
end

Policy Modules

For applications with complex permissions (roles, teams, org-level access), extract authorization into policy modules.

elixir
defmodule MyApp.Policy do
  alias MyApp.Accounts.User
  alias MyApp.Blog.Post

  def authorize(%User{role: :admin}, _action, _resource), do: :ok

  def authorize(%User{id: user_id}, :edit, %Post{user_id: user_id}), do: :ok
  def authorize(%User{id: user_id}, :delete, %Post{user_id: user_id}), do: :ok
  def authorize(%User{}, :view, %Post{published: true}), do: :ok

  def authorize(_user, _action, _resource), do: {:error, :unauthorized}
end

# Usage in LiveView
@impl true
def handle_event("delete", %{"id" => id}, socket) do
  user = socket.assigns.current_scope.user
  post = Blog.get_post!(id)

  case Policy.authorize(user, :delete, post) do
    :ok ->
      {:ok, _} = Blog.delete_post(post)
      {:noreply, push_navigate(socket, to: ~p"/posts")}

    {:error, :unauthorized} ->
      {:noreply, put_flash(socket, :error, "Not authorized")}
  end
end

Controller Authorization

Same principles apply in traditional controllers.

elixir
defmodule MyAppWeb.PostController do
  use MyAppWeb, :controller

  def delete(conn, %{"id" => id}) do
    user = conn.assigns.current_scope.user
    post = Blog.get_post!(id)

    if user.id == post.user_id do
      {:ok, _} = Blog.delete_post(post)
      redirect(conn, to: ~p"/posts")
    else
      conn
      |> put_flash(:error, "Not authorized")
      |> redirect(to: ~p"/posts")
    end
  end
end

data-confirm for Destructive Actions

Always use data-confirm on buttons that delete or irreversibly modify data.

elixir
# In HEEx template
<.button phx-click="delete" phx-value-id={post.id} data-confirm="Are you sure?">
  Delete
</.button>

# For links
<.link href={~p"/posts/#{post}"} method="delete" data-confirm="Delete this post?">
  Delete
</.link>

Testing Authorization

Test that unauthorized users cannot perform actions, not just that authorized users can.

elixir
describe "authorization" do
  test "owner can delete their post", %{conn: conn} do
    user = user_fixture()
    post = post_fixture(user_id: user.id)
    conn = log_in_user(conn, user)

    {:ok, lv, _html} = live(conn, ~p"/posts/#{post}")

    lv |> element("button", "Delete") |> render_click()
    assert_redirect(lv, ~p"/posts")
  end

  test "non-owner cannot delete post", %{conn: conn} do
    owner = user_fixture()
    other_user = user_fixture()
    post = post_fixture(user_id: owner.id)
    conn = log_in_user(conn, other_user)

    {:ok, lv, _html} = live(conn, ~p"/posts/#{post}")

    # Delete button should not be visible
    refute render(lv) =~ "Delete"

    # Even if they craft the event, server rejects it
    assert render_click(lv, "delete") =~ "Not authorized"
  end

  test "scoped query returns only user's posts" do
    user1 = user_fixture()
    user2 = user_fixture()
    post1 = post_fixture(user_id: user1.id)
    _post2 = post_fixture(user_id: user2.id)

    scope = %Scope{user: user1}
    posts = Blog.list_user_posts(scope)

    assert length(posts) == 1
    assert hd(posts).id == post1.id
  end
end

See phoenix-liveview-auth skill for authentication (who you are). See testing-essentials skill for comprehensive testing patterns.

© j-morgan6, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/phoenix-authorization-patterns of j-morgan6/elixir-phoenix-guide.

Open the folder on GitHubat commit cdfddac

Compare with similar skills

Phoenix Authorization Patterns next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Phoenix Authorization Patterns compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Phoenix Authorization Patterns this skillj-morgan6/elixir-phoenix-guide166—~2.1kAutomated safety check: PassMIT
Phx Planoliver-kriska/claude-elixir-phoenix565—~1.5kAutomated safety check: PassMIT
Planoliver-kriska/claude-elixir-phoenix565—~1.6kAutomated safety check: PassMIT
Securityoliver-kriska/claude-elixir-phoenix565—~1kAutomated safety check: PassMIT
Langfuse Enterprise Rbacjeremylongshore/tons-of-skills-marketplace2.8k—~1.9kAutomated safety check: PassMIT
Security Reviewlangfuse/langfuse36k—~1.4kAutomated safety check: PassCustom licence

Similar skills

  • Phx Plan

    oliver-kriska/claude-elixir-phoenix

    Plan features spanning multiple domains: billing (Stripe), auth (RBAC), real-time (Presence), webhooks, jobs (Oban).

    565 GitHub stars~1.5k tokensUpdated 3 days ago
    Backend & APIsAuto-check passed
  • Plan

    oliver-kriska/claude-elixir-phoenix

    Plan features spanning multiple domains: billing (Stripe), auth (RBAC), real-time (Presence), webhooks, jobs (Oban).

    565 GitHub stars~1.6k tokensUpdated 3 days ago
    Backend & APIsAuto-check passed
  • Security

    oliver-kriska/claude-elixir-phoenix

    Build and harden Phoenix auth and security — OAuth login, password hashing, sessions, RBAC, rate limiting, CSRF, XSS, SQL injection, secrets.

    565 GitHub stars~1k tokensUpdated 3 days ago
    Backend & APIsAuto-check passed
  • Langfuse Enterprise Rbac

    jeremylongshore/tons-of-skills-marketplace

    Configure Langfuse enterprise organization management and access control.

    2.8k GitHub stars~1.9k tokensUpdated today
    Backend & APIsAuto-check passed
  • Security Review

    langfuse/langfuse

    Review Langfuse changes for SSRF, tenant isolation, secret handling, unsafe redirects or uploads, RBAC drift, and client telemetry privacy.

    36k GitHub stars~1.4k tokensUpdated today
    SecurityAuto-check passed
  • Databuddy

    databuddy-analytics/Databuddy

    Integrate Databuddy analytics using the SDK, REST API, or MCP.

    1.2k GitHub stars~2.1k tokensUpdated yesterday
    Backend & APIsAuto-check passed

More from j-morgan6/elixir-phoenix-guide

All 19 skills in this repo
  • Code Quality

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when refactoring for duplication, complexity, or dead code — includes the plugin's on-demand analysis scripts.

    166 GitHub stars~1.4k tokensUpdated 3 mo ago
    Auto-check passed
  • Deployment Gotchas

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when preparing releases or deployment config — runtime.exs vs compile-time config, release migrations, PHXHOST/PHXSERVER, assets, health checks.

    166 GitHub stars~2.6k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Changeset Patterns

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when a resource needs multiple changesets (registration vs update), conditional validation, field transforms, or uniqueness validation — changeset composition.

    166 GitHub stars~2.1k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Essentials

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when defining schemas, writing queries, or creating migrations — schema design, Repo usage, indexes, query composition.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed
  • Ecto Nested Associations

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when a form or operation manages parent and child records together — castassoc/castembed, onreplace, Ecto.Multi across tables, FK cascade design.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed
  • Elixir Essentials

    j-morgan6/elixir-phoenix-guide

    A skill your agent uses when writing or refactoring core Elixir — pattern matching, case/cond/with, pipes, {:ok, }/{:error, } contracts.

    166 GitHub stars~2.2k tokensUpdated 3 mo ago
    Auto-check passed

Questions about Phoenix Authorization Patterns

What does Phoenix Authorization Patterns do?

A skill your agent uses when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers. Phoenix Authorization Patterns is an agent skill from j-morgan6/elixir-phoenix-guide. Use when deciding who may do what — ownership checks, policy modules, scoped queries, role-based access in LiveViews and controllers.

When should I use Phoenix Authorization Patterns?

Phoenix Authorization Patterns fits situations like: deciding who may do what — ownership checks; role-based access in LiveViews and controllers.

How do I install Phoenix Authorization Patterns in Claude Code?

Run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-authorization-patterns -a claude-code`. Or copy the skill folder (skills/phoenix-authorization-patterns in j-morgan6/elixir-phoenix-guide) into .claude/skills/phoenix-authorization-patterns in your project. Claude Code loads it when a task matches its description.

How do I install Phoenix Authorization Patterns in Codex?

Run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-authorization-patterns -a codex`. Or copy the skill folder (skills/phoenix-authorization-patterns in j-morgan6/elixir-phoenix-guide) into .agents/skills/phoenix-authorization-patterns in your project. Codex loads it when a task matches its description.

Can I use Phoenix Authorization Patterns in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add j-morgan6/elixir-phoenix-guide --skill phoenix-authorization-patterns -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/phoenix-authorization-patterns, .gemini/skills/phoenix-authorization-patterns, .github/skills/phoenix-authorization-patterns and .opencode/skills/phoenix-authorization-patterns in your project.

What does Phoenix Authorization Patterns need to run?

SKILL.md names no scripts, command-line tools or credentials: Phoenix Authorization Patterns is instructions for the agent only.

Does Phoenix Authorization Patterns access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Phoenix Authorization Patterns safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Phoenix Authorization Patterns use?

Phoenix Authorization Patterns is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Phoenix Authorization Patterns use?

About 2.1k tokens (SKILL.md is roughly 8.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Phoenix Authorization Patterns?

Skills that share tags, products or a category with Phoenix Authorization Patterns: Phx Plan (oliver-kriska/claude-elixir-phoenix, 565 stars), Plan (oliver-kriska/claude-elixir-phoenix, 565 stars), Security (oliver-kriska/claude-elixir-phoenix, 565 stars) and Langfuse Enterprise Rbac (jeremylongshore/tons-of-skills-marketplace, 2.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Phoenix Authorization Patterns?

j-morgan6 (a GitHub user) maintains it in j-morgan6/elixir-phoenix-guide, which has 166 GitHub stars. The repository holds 19 skills in this directory. The repository was last updated on July 6, 2026.

Source: j-morgan6/elixir-phoenix-guide on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.