Scenario · Navigation
Routing & sign-in
A page that takes route values and a query string, a sign-in, a guard that asks before you leave, and a redirect loop. BevTools → Routing answers which page this is, how the app got here and what can stop it leaving; State → Authentication answers who is signed in.
The page
The links navigate to this same page with other values: its one @page template is
/routing/{Section?}/{Id:int?}, and it reads the query through
[SupplyParameterFromQuery] properties. The last link carries an access_token, which
BevTools redacts wherever the address appears.
| Section | Id | q | page | access_token |
|---|---|---|---|---|
| orders | 1042 | – | – | given (not shown here either) |
Routing: which page is this?
- Current route: the address, the page component (
Routing), its template - labelled inferred, because this router does not report the template it matched and the page has only one - the route values (Section,Id), the query and the layout. Follow the last link: the address showsaccess_token=«redacted». - Route table: every page of the router's assemblies with its template, authorization, render mode and layout.
- Navigation history: each navigation, how long it took and what it rendered - renders and render time - newest first.
- Select
Routingin Components: the query values are parameters there too, andAccessTokenis redacted by its name.
Routing → Navigation guards: what can stop a navigation
Tick ask before leaving this page and open Routing: Navigation guards lists
the NavigationLock, whether it asks before the browser leaves the site, the callback it runs before
an internal navigation (Routing.ConfirmLeaving) and the component that registered it. Then click
any link: the callback asks you to confirm, and Cancel keeps you here. BevTools only reads the guards;
registering one of its own would make every navigation wait for .NET.
State → Authentication: who is signed in
Press Sign in as Ada, then open State and select Authentication, a state
provider BevTools adds by itself from the app's AuthenticationStateProvider: the user, the
authentication type, the roles and the claims, with a change history - anonymous → authenticated - and the
timeline entry of each change. The access_token claim is redacted; the others are shown.
Routing → Authentication shows the same at a glance, next to the route table.
Diagnostics: a redirect loop
Open the account page: it sends a visitor without a session to the login page, which sends them back, a few times before the demo stops it. Diagnostics reports a navigation loop between the two addresses, every navigation made from code rather than by a click; Navigation history lists each hop and what it rendered.