Quick Answer
- Auth Plugin's setup wizard runs four screens in order: Connect, Shields, Scripts, and Components.
- Step 1 (Connect) reads your Framer project and links it to an auth workspace, and it blocks you outright if the site isn't published yet.
- Step 2 (Shields) is the wizard's name for the same feature the dashboard sidebar calls Protected Pages, pre-populated with three suggested rules.
- Step 3 (Scripts) inserts the Shield script into headStart and the Relay script into bodyStart, tagged to your project.
- Step 4 (Components) auto-inserts Sign In Form, Sign Up Form, and Sign Out Button, and generates the Auth Plugin Overrides code file.
- The completion screen states plainly that shields don't activate until you publish, the same publish requirement that gated step 1.
The setup guide covers the wizard at a high level: run it, connect your workspace, insert scripts. This post goes one level deeper, screen by screen, what each one asks for, what it does when you click through, and what changes on your site. Based directly on the wizard's own screens.
Auth Plugin's Setup Wizard, Step by Step
The setup wizard opens inside Framer once Auth Plugin is installed on a project. Auth Plugin's own introduction page frames setup at a high level: "The 4-step wizard connects your workspace, sets up protected pages, inserts scripts, and adds starter components." The wizard runs those four screens as a fixed sequence, and each has to be completed before the next becomes available. Nothing here requires touching code, every field is either auto-filled, a toggle, or a single button press. What follows is the confirmed content of each screen.
Step 1: What Happens When You Connect Your Workspace?
The first screen is headed "Connect Your Workspace," with the subtext: "We will read your project information to set up the auth workspace." It asks for four pieces of information:
- Project ID, auto-filled and read-only. Auth Plugin generates this itself, there's nothing to type here.
- Project Name, an editable text field you can set to whatever you want the workspace called.
- Production URL, your live Framer site's URL.
- Staging URL, your Framer staging URL.
A single button, "Connect Workspace," submits the screen and creates the auth workspace tied to that project.
There's one hard blocker worth knowing before you start: if your Framer site hasn't been published yet, the wizard stops you here with a message that reads, "Site not published. Please publish your site first. Auth Plugin requires a published site to configure page protection." You can't get past step 1 on an unpublished project, and this requirement resurfaces at the very end of setup, for a different reason.
Step 2: What Happens When You Configure Shields?
Step 2 is headed "Configure Shields," with the subtext: "Select which pages to protect with authentication. Users must be logged in to access shielded pages." The wizard pre-populates three suggested shields as toggles, each with a URL pattern already filled in:
- /, pattern
.*, off by default. - /dashboard, pattern
/dashboard.*, on by default. - /account, pattern
/account.*, on by default.
Below the toggles, the wizard notes: "You can add more shields later from the Shields page." The screen ends with a "Save & Continue" button.
Here's the naming detail that trips people up after they finish setup: "Shields" is the wizard's label for the exact same feature the main dashboard sidebar calls Protected Pages. One feature, two names, depending on where you're standing in the product. Finish setup and go looking in the dashboard for a page called "Shields" and you won't find one under that name, it's sitting under Protected Pages instead. Our role-based access guide covers that dashboard feature in full, pattern syntax, redirects, and tiered access included, and it all applies to what you just configured as "shields" in the wizard.
Step 3: What Happens When You Insert Scripts?
Step 3 is headed "Insert Scripts," with the subtext: "Auth Plugin requires two scripts to be inserted into your site. The Shield script protects pages, and the Relay script handles auth state." Two scripts get inserted when you click through this screen:
- Shield script, inserted into headStart. It checks the requested URL against your shield patterns before the page's content renders, which is what makes a protected route actually block access instead of flashing content and then redirecting.
- Relay script, inserted into bodyStart and loaded as a module. It manages session state, handles token storage and refresh, and keeps auth state in sync across open tabs.
Both scripts are tagged with your project's own unique ID, so they're wired specifically to the workspace you connected in step 1, not a generic snippet. The button here reads "Insert Scripts," and clicking it confirms with a toast: "Scripts inserted successfully!"
The mechanics of the Shield and Relay scripts are described in detail in our role-based access guide. This wizard step is where those two scripts actually get inserted in the first place.
Step 4: What Happens When You Insert Components and Overrides?
The last screen is headed "Insert Components & Overrides," with the subtext: "Add authentication components to your page and generate the code overrides file for advanced customization." Clicking through this step does two things at once:
- Auto-inserts three components: Sign In Form, Sign Up Form, and Sign Out Button, three of Auth Plugin's 13 components, confirmed on the full component list, dropped onto your page ready to use.
- Generates Auth Plugin Overrides, a code overrides file for advanced auth logic. This is the same Code Overrides system covered in full in our code overrides guide, five overrides for visibility, identity injection, and sign-out, and this step is where that file first gets generated for your project.
The button reads "Insert Components & Generate Overrides," and it confirms with a toast: "Components inserted and overrides generated!"
What Does the Setup Wizard Show You When It's Done?
Once all four steps are complete, the wizard shows a completion screen with this message: "Setup Complete! Your auth workspace is ready. Publish your site to activate shields."
That last sentence is doing real work and easy to skim past. It's the confirmed reason a freshly configured shield doesn't actually block anyone the moment you finish the wizard, the shield and relay scripts you just inserted in step 3, along with the shield rules you toggled in step 2, only take effect once the site is published with those changes live.
Why Does Publish Status Matter at Both Ends of Setup?
Publishing shows up twice, and both times it's the same underlying requirement. At the start, step 1 refuses to connect a workspace at all until your site is published, because Auth Plugin needs a live site to read project information from. At the end, the completion screen tells you the shields you just configured won't activate until you publish again with the new scripts and settings included.
Don't treat "I finished the wizard" as "my pages are protected." Between clicking "Insert Components & Generate Overrides" and actually publishing, your site runs without the shield and relay scripts live, so none of the access rules from step 2 are enforced yet. Publish before you consider setup done.
FAQ
Is Auth Plugin's setup wizard the same as the Protected Pages page in the dashboard?
They cover the same feature under different names. The wizard calls it Shields, the dashboard sidebar calls it Protected Pages. What you configure in step 2 of the wizard is the same rule set you'll later manage from the Protected Pages page.
Do I need my Framer site published before I can start setup?
Yes. Step 1 checks for a published site and blocks you with an explicit message if it isn't published yet. Auth Plugin needs a live site to read project information from before it can connect a workspace.
Which pages does the wizard protect by default?
It suggests three shields: / (off by default), /dashboard (on by default), and /account (on by default). You can toggle any of them before continuing, and add more later from the Shields or Protected Pages page.
What are the Shield script and Relay script, and where do they get inserted?
The Shield script goes into headStart and checks the requested URL against your shield patterns before content renders. The Relay script goes into bodyStart as a module and manages session state, token handling, and cross-tab auth sync. Step 3 of the wizard is what inserts both.
Does the wizard add a sign-in form automatically?
Yes. Step 4 auto-inserts Sign In Form, Sign Up Form, and Sign Out Button onto your page, and generates the Auth Plugin Overrides code file in the same step.
Do my shields work as soon as the wizard finishes?
No. The completion screen says explicitly that you need to publish your site to activate shields. Finishing the wizard configures everything, publishing is what makes it live.
The Short Version
Auth Plugin's setup wizard runs four fixed screens: Connect, Shields, Scripts, and Components. Connect reads your project and requires a published site before it will proceed. Shields, the same feature the dashboard calls Protected Pages, pre-populates three suggested rules for /, /dashboard, and /account. Scripts inserts the Shield script into headStart and the Relay script into bodyStart, both tagged to your project. Components auto-inserts Sign In Form, Sign Up Form, and Sign Out Button, and generates the Auth Plugin Overrides file. The completion screen's closing line matters most: your shields don't activate until you publish, so treat publishing as the real last step, not the wizard's final button press.
