Skip to content

docs: clarify User model + AUTH_MODEL behaviour#1

Open
Ynitial wants to merge 1 commit into
mainfrom
docs/clarify-user-model
Open

docs: clarify User model + AUTH_MODEL behaviour#1
Ynitial wants to merge 1 commit into
mainfrom
docs/clarify-user-model

Conversation

@Ynitial
Copy link
Copy Markdown
Contributor

@Ynitial Ynitial commented May 4, 2026

Summary

Two README fixes:

  1. Add an Authentication section explaining that Backstage's User model is loaded by default via the AUTH_MODEL env var (which the installer sets post-install). Most projects don't need to create app/Models/User.php at all.

  2. Warn against re-introducing protected \$guarded = []; when extending Backstage\Models\User from a project-side User class. The parent declares an explicit \$fillable whitelist; an empty \$guarded would override it and turn a future User::create(\$request->all()) into a privilege-escalation footgun.

  3. Drive-by: fix the inverted markdown link in the intro ([url](text) was swapped — the URL was rendering as link text and the word "Backstage" was the destination).

Why

Noticed during a pre-launch security audit on a downstream Backstage project. The project had its own app/Models/User.php extending Backstage\Models\User and a leftover protected \$guarded = []; from Laravel's default skeleton — together those re-opened mass assignment on the User row.

Stage's design is correct as-is: it ships no app/Models/User.php and the installer wires up AUTH_MODEL so Backstage's User is used directly. This PR just makes that explicit in the README so future projects don't silently hand-roll their own User class out of habit and re-introduce the same hole.

Test plan

  • README renders cleanly on github.com (link fix lands, new Authentication section reads correctly)
  • No code touched — no functional changes to verify

🤖 Generated with Claude Code

Two related fixes to README.md:

1. Add an Authentication section explaining that Backstage's User
   model is loaded by default via the AUTH_MODEL env var (set by
   the installer post-install). Most projects don't need to create
   app/Models/User.php at all.

2. Warn against re-introducing `protected $guarded = [];` when
   extending Backstage\Models\User from a project-side User class.
   The parent declares an explicit $fillable whitelist; an empty
   $guarded would override it and turn a future
   User::create($request->all()) into a privilege-escalation
   footgun.

3. (Drive-by) fixed the inverted markdown link in the intro -
   `[url](text)` was swapped, displayed the URL as link text and
   the word "Backstage" as the destination.

Context: noticed during a pre-launch security audit on a downstream
project where extending the parent User class without dropping the
default Laravel-skeleton `$guarded = []` re-opened mass-assignment.
The behaviour is correct in stage as-is - this PR just documents
how to extend without breaking it.
@Ynitial Ynitial requested a review from mhortulanus May 4, 2026 12:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant