diff --git a/.github/agents/issue-triage-nonblazor.agent.md b/.github/agents/issue-triage-nonblazor.agent.md index f6b0a02c5e08..4078b5fd55f0 100644 --- a/.github/agents/issue-triage-nonblazor.agent.md +++ b/.github/agents/issue-triage-nonblazor.agent.md @@ -67,7 +67,10 @@ If any content is not in English: ### File Naming `-analysis-report.md` +Provide a link to the report file, an absolute link that can be clicked on from anywhere. + ### Report Structure +Eliminate duplicate report content that may arise from running the analysis more than one time on an issue. #### Header (REQUIRED - Always include this community-facing notice) ```markdown diff --git a/aspnetcore/blazor/security/index.md b/aspnetcore/blazor/security/index.md index eec3fd2231e0..9c5d0408e526 100644 --- a/aspnetcore/blazor/security/index.md +++ b/aspnetcore/blazor/security/index.md @@ -92,7 +92,7 @@ For more information, see the following resources: Server-side Blazor apps are configured for security in the same manner as ASP.NET Core apps. For more information, see the articles under . -The authentication context is only established when the app starts, which is when the app first [connects to the WebSocket over a SignalR connection](xref:signalr/authn-and-authz) with the client. Authentication can be based on a cookie or some other bearer token, but authentication is managed via the SignalR hub and entirely within the [circuit](xref:blazor/hosting-models#blazor-server). The authentication context is maintained for the lifetime of the circuit. Apps periodically revalidate the user's authentication state every 30 minutes. +The authentication context is only established when the app starts, which is when the app first [connects to the WebSocket over a SignalR connection](xref:signalr/authn-and-authz) with the client. Authentication can be based on a cookie or some other bearer token, but authentication is managed via the SignalR hub and entirely within the [circuit](xref:blazor/hosting-models#blazor-server). The authentication context is maintained for the lifetime of the connection and is re-evaluated on reconnection. If the app must capture users for custom services or react to updates to the user, see .