You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Scope dashboard cookies and resource state by application name - #20299
Scope dashboard authentication and antiforgery cookie names by application name, and make application-scoped collapsed-resource storage keys collision-resistant.
Cookies are shared across ports on the same hostname. Previously, dashboards running on localhost used fixed authentication and antiforgery cookie names, allowing their cookies to interfere with one another. Collapsed-resource preferences already included the application name, but removed non-alphanumeric characters, causing names such as my-app and my app to use the same storage key.
Changes
Introduce a shared application-key helper using a lowercase, cookie-safe prefix of up to 32 characters plus an XxHash3 hash of the full application name. The hash preserves distinctions lost through sanitization, truncation, or lowercasing.
Scope both HTTP and HTTPS authentication cookie names for browser-token and OpenID Connect authentication, along with the antiforgery cookie name, using the configured application name.
Use the shared helper for collapsed-resource local-storage keys, retaining the existing use of the application name supplied by the connected resource service.
Centralize the null/empty/whitespace application-name fallback to Aspire for configuration consumers and dashboard clients. Existing disk-persistence naming remains unchanged.
Add focused cookie, storage-key, component, and browser isolation coverage, and document the application-name configuration's role in cookie and disk-data scoping.
Usage and compatibility
Configure a distinct name for dashboards whose cookies should be kept separate:
{
"Dashboard": {
"ApplicationName": "My application"
}
}
Cookie names include an application-specific suffix, for example .Aspire.Dashboard.Auth.my-application-<hash> and .Aspire.Dashboard.Antiforgery.my-application-<hash>. Dashboards configured with the same application name still use the same cookie names.
Existing authentication cookies and collapsed-resource preferences are not migrated to the new names: users will need to sign in again, and resource expansion state will initially reset. Data persisted on disk retains its existing keys.
This does not make all browser settings application-specific. Preferences such as time format can still be shared when applications reuse the same browser origin. Collapsed-resource state follows the connected resource service's application name, which can differ from the configured name used for cookies and disk persistence.
Security considerations
Application-name scoping avoids accidental cookie/key collisions; it is not a security boundary. XxHash3 is a non-cryptographic naming hash, not an authentication or integrity mechanism. Existing cookie protection and authentication validation remain in place.
Validation
Validated the implementation at 950de65a10:
DashboardOptionsTests and FrontendBrowserTokenAuthTests: 55 passed, including the new antiforgery-name test.
Storage-key collision tests: 3 passed.
Collapsed-resource component test: 1 passed.
Real dashboard/browser checks: same-name instances shared authentication, different-name instances required separate login, signing into one application preserved the other's authentication, and application-specific authentication and antiforgery cookies coexisted.
Same-origin resource-collapse checks: state survived reload and remained independent between application names with identical sanitized prefixes but different hashes.
The PR also adds an outerloop Playwright theory for same-name versus different-name browser-token authentication. Live OpenID Connect provider flows and the HTTPS browser matrix were not exercised during the manual checks.
Checklist
Is this feature complete?
Yes. Ready to ship.
No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
Yes
No
Did you add public API?
Yes
If yes, did you have an API Review for it?
Yes
No
Did you add <remarks /> and <code /> elements on your triple slash comments?
Yes
No
No
Does the change make any security assumptions or guarantees?
Yes
If yes, have you done a threat model and had a security review?
The reason will be displayed to describe this comment to others. Learn more.
Copilot review overview
🔵 Needs a closer look
Run metadata must store the effective fallback name to prevent historical runs from using inconsistent application names and browser-storage keys.
Review effort: Balanced Findings: None
James Newton-King (JamesNK)
changed the title
Scope dashboard auth cookies by application name
Scope dashboard cookies and resource state by application name
Sep 23, 2026
A proto3 resource service can omit application_name, which materializes as an empty string. After _applicationName is assigned that value, this null-coalescing expression returns it unchanged, so the live client still bypasses the new empty/whitespace fallback and derives collapsed-resource state from an empty name rather than Aspire. Normalize the service-provided value as well as the configured fallback.
Preserve the live client name for current runs and normalize legacy historical metadata. Cover fallback names and run switching with regression tests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Documents the application-name-based cookie scoping introduced in
microsoft/aspire#20299: authentication (browser-token and OpenID
Connect) and antiforgery cookie names now include a suffix derived
from Dashboard:ApplicationName, so dashboards with different
application names no longer share cookies.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Triggered signal: pr_body_has_user_facing_section (evidence: PR body's "### Usage and compatibility" section describing the new Dashboard:ApplicationName cookie-scoping behavior).
Documented the application-name-based cookie scoping introduced by the PR:
Updated the Dashboard:ApplicationName row in dashboard/configuration.mdx to mention cookie scoping and link to the new security-considerations section.
Added a new "Cookie scoping by application name" section to dashboard/security-considerations.mdx explaining why cookies are scoped (shared cookies across ports on the same hostname), how the suffix is derived (cookie-safe prefix + hash), the example cookie names from the PR body, that changing the name requires re-signing-in, and that this is a collision-avoidance mechanism, not a security boundary — cross-referencing the existing data-persistence.mdx#storage-layout section for the related collapsed-resource storage-key scoping.
…ion name (#20407)
Backport of #20299 to release/13.6
/cc @JamesNK
## Customer Impact
Dashboards sharing a hostname could interfere with one another’s
authentication and antiforgery cookies. Resource-collapse preferences
could also collide for application names with the same sanitized form.
Existing users will need to sign in again and will initially lose their
saved resource expansion state.
## Testing
Dashboard and component test CI passed on Windows and Linux for this
backport; Ubuntu x64 native-AOT Dashboard validation passed. The source
PR reports focused cookie/storage tests and manual browser checks of
same-name and different-name dashboard isolation. Live OpenID Connect
and HTTPS browser flows were not manually exercised.
## Risk
Medium. Cookie and storage names change across dashboard authentication
modes; existing cookies and collapsed-resource preferences are not
migrated, requiring reauthentication and resetting those preferences.
## Regression?
Unknown — please confirm.
---------
Co-authored-by: James Newton-King <james@newtonking.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ps (#1780)
## Summary
<!-- Describe what this pull request changes and why. -->
Reconcile the 13.6 wiki audit and **all 25 open `docs-from-code`
proposals targeting `release/13.6`** against the actual release source.
Add missing canonical guidance rather than putting all coverage in
What's new. This is a new, isolated feature PR into `release/13.6`; it
does not update the release rollup #1599, merge or close another
proposal, or push directly to a release branch.
**Draft with explicit remaining packaging/validation gates:** the six
REPL walkthroughs are source-verified, but current publicly available
13.6 packages do not contain the late `WithRepl` exports. Generated API
catalogs have deliberately not been fabricated or refreshed from 14.x.
See the open checklist below.
### Evidence baseline
- Documentation base: `717442f6666948bcf77f3d704dc2dadf7c080ec2`.
- Product source of truth:
[`microsoft/aspire@e8fd6fbb954f50ccd2e66479538392f65e13e71d`](https://github.com/microsoft/aspire/tree/e8fd6fbb954f50ccd2e66479538392f65e13e71d),
current `release/13.6` at audit time. Source was read from that Git
object, not the stale source working directory.
- [13.6 wiki](https://github.com/microsoft/aspire/wiki/13.6-Change-log)
snapshot `8e01a371d4f16a1306e48174d4cf1fdeca714348`, whose cutoff is
product PR 20511. Later backports 20541/20546/20548 are included here.
- Proposal base branches alone were **not** used as proof of release
membership. Direct ancestry and known release backports were checked.
Four fallback-targeted proposals are excluded below.
- Wiki link corrections: its REPL link #1752 actually covers Sandboxes;
the REPL proposal is #1740. Its AOT link #1714 covers PFX certificates,
not AOT.
### Complete audit-gap checklist
Checked items mean documentation coverage is implemented, not that cloud
deployment or every product runtime scenario was executed.
- [x] **1. Dotnet API graduation:** correct removal to **13.6**, not
14.0, in What's new, both Dotnet guides, and the diagnostic page;
preserve the prerelease package caveat. This applies to core
`AddDotnetProject`, `DotnetProjectResource`, and related
`WithBuildEnvironment` overloads, not all uses of the diagnostic.
Source: microsoft/aspire#20496.
- [x] **2. Sandboxes:** remove obsolete API suppressions in the article
and deployment guide while preserving Azure service preview/access and
prerelease package limitations. Source: microsoft/aspire#20483.
- [x] **3. Docked REPL documentation:** all six
PostgreSQL/MySQL/MongoDB/SQL Server/Redis/Valkey guides plus the article
now cover opt-in `WithRepl`/`withRepl`, run-only availability, actual
client privileges, credential handling, and explicit exit versus closing
a viewer. Source: microsoft/aspire#20419, backport of
microsoft/aspire#20231. Package-backed checks remain open below.
- [x] **4. Terminal CLI flag:** update current 13.6 article,
`with-terminal`, and all three terminal command references. Preserve
`terminals.v1` and experimental hosting API distinctions. Current
configuration/schema data had no flag entry to remove; historical 13.5
notes remain historical. Source: microsoft/aspire#20548.
- [x] **5. First-party Rust:** rewrite both canonical Rust guides around
`Aspire.Hosting.Rust`; document Cargo versus application arguments,
typed targets, debugging, generated Dockerfiles, workspace context, ABI
constraints, and Toolkit migration. Bacon remains explicitly
Toolkit-only. Add exact first-party package mapping. Source:
microsoft/aspire#18906 and current Rust README.
- [x] **6. Agent setup:** align command reference, skills guide,
AI-agent guide, and article on MCP opt-in, `--mcp`,
chained/non-interactive behavior, seven-skill catalog, Project v2
migration, and Copilot app detection. Also fix stale default-selection
text: all applicable bundle skills are preselected; companion tools
remain opt-in. Sources: microsoft/aspire#19893, microsoft/aspire#20405,
microsoft/aspire#19820.
- [x] **7. Deno AppHost runtime:** document Deno 2+ detection, commands,
permissions, native watch/type checking, doctor, and `DENO_CERT`,
separately from Deno guest hosting. Source: microsoft/aspire#18627,
distinct from microsoft/aspire#18628.
- [x] **8. Native AOT / Fluent UI v5:** concise article, dashboard
exploration, and standalone guidance; automatic packaged-dashboard
selection, no invented performance figures. Source:
microsoft/aspire#19565 and release packaging sources.
- [x] **9. NuGet:** document bundled in-process operations, credential
providers, non-interactive authentication, and realistic
troubleshooting. Correct the proposal's `dotnet nuget locals`
authentication advice: cache commands do not authenticate a feed.
Source: microsoft/aspire#20391.
- [x] **10. Multithreaded builds:** article and coordinated-build guide
explain `-mt`, SDK detection, distinct project/file-based SDK floors,
and fallback. Source: microsoft/aspire#20441.
- [x] **11. Radius:** add a real deployment guide with C#/TypeScript
setup, recipe-backed connections versus local endpoints, per-resource
credential behavior, unauthenticated Redis limitation, secret exposure
boundaries, and actionable runtime diagnostics 070–091. Wire navigation
and exact package mapping. Source: microsoft/aspire#19555 and release
README.
- [x] **12. Connection aliases:** replace contradictory no-encoding
guidance, retain composed logical-key-first lookup and portable-target
behavior, explain collision detection and custom-publisher metadata.
Source: microsoft/aspire#19729.
- [x] **13. Connector Namespace / Toolbox / provisioning:** add
Connector Namespace walkthrough, security/consent/revocation limits and
mapping/sidebar; add Foundry Toolbox walkthrough, connection properties,
roles, index prerequisites, approval enforcement boundaries, immutable
versions, and existing-resource behavior. Extend existing Azure
provisioning guide without a duplicate page. Sources:
microsoft/aspire#19024, microsoft/aspire#17742, microsoft/aspire#20131.
- [x] **14. Remaining high-impact items:** article covers opt-in
manifest-aware DNX and new-template CLI bundling (existing SDK guides
retained), migration skill and Copilot app detection; canonical inline
`CsiVolumeSourceV1`/`VolumeV1.Csi` example, management links, Cosmos
vNext telemetry, and AI Inference `GetModelInfoAsync`/`/info` health
checks with `DisableHealthChecks`. No Azure OpenAI health-check claim.
Sources: microsoft/aspire#19310, microsoft/aspire#19076,
microsoft/aspire#19826, microsoft/aspire#20070, microsoft/aspire#15671,
microsoft/aspire#15969.
- [x] **15. All 25 proposal dispositions:** listed below, including
newer dashboard backports and four exclusions. Existing Sandbox
inference coverage is retained rather than copied from a stale draft.
- [ ] **16. Refresh generated API/catalog/Twoslash data from an official
post-backport 13.6 build.** Existing `26473.12`/`a11eca96` data remains
untouched. The newest public `dotnet9` feed package checked,
`13.6.0-preview.1.26474.10` at
`43496a2a306c81c862c947b11b4f4e5494b6fe08`, still has no Redis
`WithRepl` in its actual package XML. Do not use 14.x, hand-edit
declarations, or attribute source changes to older binaries.
- [ ] **Validate the six REPL examples against that actual post-backport
SDK and running clients.** Their new TypeScript fences are plain
TypeScript, not annotated with unsupported Twoslash data. No existing
diagnostics are allowlisted or suppressed; no generated API exports are
fabricated. Enable Twoslash when the genuine catalog catches up.
### All 25 open proposal dispositions and provenance
Text is selectively adapted from these proposals, not merged wholesale.
#1778 and #1748 are authored by @sebastienros; the other proposals are
authored by the Aspire repo bot. The table credits the associated
product-change authors where supplied by the proposals. Existing PRs
remain open and unchanged.
| Docs PR | Release source / credited product author | Disposition |
| --- | --- | --- |
| #1778 | microsoft/aspire#19729 — @sebastienros | **Adopted:**
canonical connection-string alias correction, including logical-first
resolution and migration. |
| #1771 | microsoft/aspire#20481 — @sebastienros | **Excluded:** flat
polyglot feature keys are not in the audited release tip; no verified
backport. Preserve release key names. |
| #1770 | microsoft/aspire#20525 → microsoft/aspire#20548 — @mitchdenny
| **Corrected/adopted:** command guides plus the still-current 13.6
article, which the proposal incorrectly treats as historical. |
| #1769 | microsoft/aspire#20416 — @JamesNK | **Excluded:** brand hover
change has no verified 13.6 membership/backport. |
| #1768 | microsoft/aspire#20523 → microsoft/aspire#20546 — @JamesNK |
**Adopted:** run pin/unpin preserves selector and current selection. |
| #1766 | microsoft/aspire#20537 → microsoft/aspire#20541 — @mitchdenny
| **Adopted:** terminal dock empty state. |
| #1761 | microsoft/aspire#20490 → microsoft/aspire#20496 — @eerhardt |
**Corrected:** graduation is 13.6, package remains prerelease,
Blazor-specific exception retained. |
| #1760 | microsoft/aspire#20436 — @eerhardt | **Excluded:** CLI
net11/tools-any retarget is not in the audited release; no fallback-base
inference. |
| #1748 | microsoft/aspire#20131 — @sebastienros | **Adopted:** extend
existing provisioning guide with service-specific models/lookups and
projection limits. |
| #1744 | microsoft/aspire#20337 → microsoft/aspire#20441 — @karolz-ms |
**Adopted:** precise SDK-conditional multithreaded build coverage. |
| #1740 | microsoft/aspire#20231 → microsoft/aspire#20419 — @mitchdenny
| **Adapted:** all six guides; TypeScript-first tabs, source-verified
lifecycle/security. Actual post-backport SDK/runtime gate is open above.
|
| #1738 | microsoft/aspire#20158 → microsoft/aspire#20405 — @karolz-ms |
**Partly already covered / completed:** existing seven-skill catalog
retained; add project migration guidance and correct command
catalog/defaults. Do not misclassify the bundled skill as a companion
tool. |
| #1735 | microsoft/aspire#20334 — @karolz-ms | **Excluded:** enhanced
startup errors are not in the audited release; no verified backport. |
| #1731 | microsoft/aspire#19847 → microsoft/aspire#20391 — @eerhardt |
**Corrected/adopted:** in-process NuGet and real authenticated-restore
troubleshooting, not cache-command authentication. |
| #1719 | microsoft/aspire#20299 → microsoft/aspire#20407 — @JamesNK |
**Corrected/adopted:** cookie naming/scoping; identical names can
collide but do not guarantee cross-dashboard cookie decryptability or
shared sign-in. |
| #1664 | microsoft/aspire#20011 — @maddymontaquila | **Adopted:**
concise Azure environment icon release note. |
| #1628 | microsoft/aspire#17742 — @davidfowl | **Adapted/expanded:**
canonical Toolbox examples, consumer contract, role/index prerequisites,
approval/security and concurrency limits. |
| #1623 | microsoft/aspire#19810 — @mitchdenny | **Already covered:**
current Sandbox guide/article already describe compute inference,
explicit selection and external endpoints. Preserve that guidance while
removing obsolete suppressions. |
| #1620 | microsoft/aspire#19243 — @sebastienros | **Adapted:** AKS
credential-before-Helm cleanup and destructive-operation warning; omit
misleading ambient-context workaround. |
| #1614 | microsoft/aspire#19870 — @sebastienros | **Adopted:** typed
callback handle behavior in extension authoring and article. |
| #1574 | microsoft/aspire#19430 — @mitchdenny | **Adapted:** canonical
hostname inheritance, explicit-host precedence, catch-all default
backend. |
| #1570 | microsoft/aspire#19590 — @karolz-ms | **Adopted:** Dev Tunnel
URL regression troubleshooting. |
| #1565 | microsoft/aspire#19429 — @mitchdenny | **Corrected/adopted:**
Helm embedded parameters with real `refExpr` and `addParameter(name, {
value })`, not stringifying a handle or using an invalid actual-SDK
overload. |
| #1564 | microsoft/aspire#19026 — @karolz-ms | **Corrected/adopted:**
C#/TypeScript Dotnet gateway walkthrough. Retain both experimental
diagnostics; remove obsolete run-only restriction after
microsoft/aspire#19997 publishing support. Avoid imported ambiguous API
reference. |
| #1499 | microsoft/aspire#19248 — @IEvangelist | **Adopted:** describe
exact secret-value redaction and embedded-secret limit; release article
already covered the fix. |
### Important source-verified corrections to proposals / earlier audit
assumptions
-
[`BlazorGatewayExtensions.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Hosting.Blazor/BlazorGatewayExtensions.cs):
`AddDotnetProjectBlazorGateway` and the Dotnet `WithBlazorClientApp`
overload still carry `ASPIREDOTNETPROJECT001`; the class carries
`ASPIREBLAZOR001`. They share `WithBlazorClientAppCore`/`WithBlazorApp`
and the publish-companion path. Thus neither blanket diagnostic
retirement nor the proposal's old run-only claim is correct.
-
[`SkillDefinition.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Agents/SkillDefinition.cs)
sets bundled skills' `IsDefault=true`;
[`AgentInitCommand.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Commands/AgentInitCommand.cs)
selects the applicable catalog defaults for both flows. MCP has its own
standalone-only binding.
-
[`TypeScriptAppHostToolchainResolver.cs`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Cli/Projects/TypeScriptAppHostToolchainResolver.cs)
is the source for Deno flags and certificate variable; guest Deno
hosting is separate.
- [`Radius
README`](https://github.com/microsoft/aspire/blob/e8fd6fbb954f50ccd2e66479538392f65e13e71d/src/Aspire.Hosting.Radius/README.md)
supplies the resource-specific credential rules and publish diagnostics,
not assumptions about local endpoints.
## Third-party links and affiliations
<!-- List third-party links and disclose material affiliations. -->
Links point to official Microsoft Learn, VS Code Marketplace debugger
extensions, Rust/Cargo/Bacon documentation, Radius documentation, and
source repositories. No sponsorship, commercial endorsement, or
affiliation claim is introduced. Maintainers should supply any personal
affiliation disclosure required by policy; automation has not inferred
one.
## Validation
<!-- List the checks you ran or explain why validation isn't needed. -->
- **97 passing focused unit checks** across API-reference
authoring/rendering, Twoslash blocks, file-tree formatting, CLI
configuration schema, SEO lengths, and resource catalog.
- **82 passing structured-data checks**, including exact integration
mapping uniqueness and page resolution.
- **11 C# samples compile**, zero warnings/errors, using genuine
`13.6.0-preview.1.26473.12` packages. Scope: Rust, Connector Namespace,
Radius, Toolbox, inline CSI, Helm, Blazor gateway, and provisioning.
`Projects.Api/Worker/Client` use compile-only `IProjectMetadata`
stand-ins; no claim of running those apps or provisioning cloud
resources.
- **10 TypeScript samples pass `tsc`** under `strict`, `NodeNext`, and
`ES2022` against three **unmodified actual SDK files**, not just the
site's declaration bundle. The fixture uses the exact `e8fd6fbb` release
`AtsCapabilityScanner` and genuine `26473.12`
TypeSystem/code-generator/integration binaries, whose informational
source is `a11eca96`. This is an isolated local generation fixture,
**not** a claim that official CLI generation or a new packaged release
was tested. An attempted restore with the older handed-off local CLI
could not discover an AppHost server; the bounded direct generator
fixture was used instead.
- The SDK scan is **not globally warning-free**: it reports a Radius
`withContainerImage` collision on `CSharpAppResource` and an App
Configuration `createRoleAssignment` overload collision. None of the
compiled examples calls those colliding methods; the warnings are
retained in evidence, not suppressed, and no generated declarations were
edited.
- Browser: Connector Namespace, Radius, both Rust pages, Foundry
hosting, and What's new return **HTTP 200**, correct headings, and no
rendered Twoslash errors. New guide/article page-local anchors and the
cross-page Blazor anchor resolve. Connector/Radius mobile layouts have
no horizontal overflow; Connector language-tab interaction works.
Standalone Astro preview emits expected `/api/live` 404s because
StaticHost is not running.
- `git diff --check` passes. No production `pnpm build`, cloud
deployment, REPL runtime session, full product suite, or blanket
validation of every pre-existing example was performed.
- Generated C#/TypeScript API data, declaration bundles, integration
catalogs, image catalogs, and contributor data are unchanged. Only the
authored package-to-guide mapping is updated.
**Before merging:** complete the two packaging/REPL checkboxes above,
inspect CI, and obtain human review. This PR intentionally does not
close or merge the source documentation proposals.
---------
Co-authored-by: David Pine <7679720+IEvangelist@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…ion name (#20407)
Backport of #20299 to release/13.6
/cc @JamesNK
## Customer Impact
Dashboards sharing a hostname could interfere with one another’s
authentication and antiforgery cookies. Resource-collapse preferences
could also collide for application names with the same sanitized form.
Existing users will need to sign in again and will initially lose their
saved resource expansion state.
## Testing
Dashboard and component test CI passed on Windows and Linux for this
backport; Ubuntu x64 native-AOT Dashboard validation passed. The source
PR reports focused cookie/storage tests and manual browser checks of
same-name and different-name dashboard isolation. Live OpenID Connect
and HTTPS browser flows were not manually exercised.
## Risk
Medium. Cookie and storage names change across dashboard authentication
modes; existing cookies and collapsed-resource preferences are not
migrated, requiring reauthentication and resetting those preferences.
## Regression?
Unknown — please confirm.
---------
Co-authored-by: James Newton-King <james@newtonking.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Scope dashboard authentication and antiforgery cookie names by application name, and make application-scoped collapsed-resource storage keys collision-resistant.
Cookies are shared across ports on the same hostname. Previously, dashboards running on localhost used fixed authentication and antiforgery cookie names, allowing their cookies to interfere with one another. Collapsed-resource preferences already included the application name, but removed non-alphanumeric characters, causing names such as
my-appandmy appto use the same storage key.Changes
Aspirefor configuration consumers and dashboard clients. Existing disk-persistence naming remains unchanged.Usage and compatibility
Configure a distinct name for dashboards whose cookies should be kept separate:
{ "Dashboard": { "ApplicationName": "My application" } }Cookie names include an application-specific suffix, for example
.Aspire.Dashboard.Auth.my-application-<hash>and.Aspire.Dashboard.Antiforgery.my-application-<hash>. Dashboards configured with the same application name still use the same cookie names.Existing authentication cookies and collapsed-resource preferences are not migrated to the new names: users will need to sign in again, and resource expansion state will initially reset. Data persisted on disk retains its existing keys.
This does not make all browser settings application-specific. Preferences such as time format can still be shared when applications reuse the same browser origin. Collapsed-resource state follows the connected resource service's application name, which can differ from the configured name used for cookies and disk persistence.
Security considerations
Application-name scoping avoids accidental cookie/key collisions; it is not a security boundary. XxHash3 is a non-cryptographic naming hash, not an authentication or integrity mechanism. Existing cookie protection and authentication validation remain in place.
Validation
Validated the implementation at
950de65a10:DashboardOptionsTestsandFrontendBrowserTokenAuthTests: 55 passed, including the new antiforgery-name test.The PR also adds an outerloop Playwright theory for same-name versus different-name browser-token authentication. Live OpenID Connect provider flows and the HTTPS browser matrix were not exercised during the manual checks.
Checklist
<remarks />and<code />elements on your triple slash comments?