Improve user session management in Boilerplate (#10894) #10895
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis update refactors user session management in the Boilerplate project template. It introduces a new endpoint and DTO for updating user session properties, expands the Changes
Sequence Diagram(s)sequenceDiagram
participant ClientApp
participant IUserController
participant ServerDB
ClientApp->>IUserController: UpdateSession(UpdateUserSessionRequestDto)
IUserController->>ServerDB: Update session (AppVersion, DeviceInfo, PlatformType, CultureName)
ServerDB-->>IUserController: Update result
IUserController-->>ClientApp: Success/Error
sequenceDiagram
participant Client
participant SignalR Hub
participant SnackBarService
SignalR Hub->>Client: SHOW_MESSAGE(message, data, returnValue)
Client->>SnackBarService: ShowNotification(message, data)
alt Notification supported
SnackBarService-->>Client: true
else Notification with payload not supported
SnackBarService-->>Client: false
end
Client-->>SignalR Hub: Return value (shown or not)
Assessment against linked issues
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (5)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Models/Identity/UserSession.cs (1)
49-49: Add XML documentation for consistency.The
DeviceInfoproperty lost its XML documentation when moved. Consider adding documentation to maintain consistency with the other properties.+ /// <summary> + /// Information about the device used for this session. + /// </summary> public string? DeviceInfo { get; set; }src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/AppPlatform.cs (1)
37-43: Consider using a switch expression for better readability.The ternary chain works but could be more maintainable with a switch expression.
- public static AppPlatformType Type => - IsAndroid ? AppPlatformType.Android : - IsIOS ? AppPlatformType.iOS : - IsWindows ? AppPlatformType.Windows : - IsMacOS ? AppPlatformType.macOS : - IsLinux ? AppPlatformType.Linux : AppPlatformType.Web; + public static AppPlatformType Type => (IsAndroid, IsIOS, IsWindows, IsMacOS, IsLinux) switch + { + (true, _, _, _, _) => AppPlatformType.Android, + (_, true, _, _, _) => AppPlatformType.iOS, + (_, _, true, _, _) => AppPlatformType.Windows, + (_, _, _, true, _) => AppPlatformType.macOS, + (_, _, _, _, true) => AppPlatformType.Linux, + _ => AppPlatformType.Web + };src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/HttpMessageHandlers/RequestHeadersDelegatingHandler.cs (2)
28-29:❓ Verification inconclusive
Enhanced telemetry with app version and platform headers.
Adding
X-App-VersionandX-App-Platformheaders to all outgoing requests provides valuable telemetry data for session management and debugging. This aligns well with the PR's objective to improve user session management.Consider adding null/empty checks for the header values to prevent potential issues:
- request.Headers.Add("X-App-Version", telemetryContext.AppVersion); - request.Headers.Add("X-App-Platform", AppPlatform.Type.ToString()); + if (!string.IsNullOrEmpty(telemetryContext.AppVersion)) + request.Headers.Add("X-App-Version", telemetryContext.AppVersion); + + request.Headers.Add("X-App-Platform", AppPlatform.Type.ToString());Please verify that the server-side can properly handle these new headers:
🏁 Script executed:
#!/bin/bash # Description: Check if server-side controllers or middleware handle the new headers # Search for header processing in controllers or middleware rg "X-App-Version|X-App-Platform" -A 3 -B 3 # Search for telemetry context usage in server code rg "telemetryContext|TelemetryContext" -A 2Length of output: 31167
Ensure safe header addition and server-side support
Add null/empty checks before adding both telemetry headers to prevent runtime errors if values are missing:
- request.Headers.Add("X-App-Version", telemetryContext.AppVersion); - request.Headers.Add("X-App-Platform", AppPlatform.Type.ToString()); + if (!string.IsNullOrEmpty(telemetryContext.AppVersion)) + request.Headers.Add("X-App-Version", telemetryContext.AppVersion); + + var platformValue = AppPlatform.Type.ToString(); + if (!string.IsNullOrEmpty(platformValue)) + request.Headers.Add("X-App-Platform", platformValue);• Verify that your server-side controllers or middleware have been updated to read and process
X-App-VersionandX-App-Platform.
• Without corresponding server support, these headers will be silently ignored.
28-30: Excellent enhancement for session management tracking.Adding app version and platform headers to all requests provides valuable telemetry data that aligns perfectly with the PR's objective of improving user session management. This will help the server track client information consistently.
Consider whether these headers should be conditionally added to avoid including them in requests where they might not be needed (e.g., static resource requests), though the current implementation is acceptable for most scenarios.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/ClientAppCoordinator.cs (1)
160-163: Consider adding error handling for UpdateUserSession.While the placement after authentication check is correct, consider wrapping the
UpdateUserSessioncall in a try-catch to prevent failures from interrupting the authentication state propagation flow.if (isAuthenticated) { - await UpdateUserSession(); + try + { + await UpdateUserSession(); + } + catch (Exception ex) + { + logger.LogWarning(ex, "Failed to update user session"); + // Continue with auth state propagation even if session update fails + } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Knowledge Base: Disabled due to Reviews > Disable Knowledge Base setting
📒 Files selected for processing (40)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/ClientAppCoordinator.cs(6 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Management/RolesPage.razor.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/ProfileSection.razor.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/SessionsSection.razor.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/ConfirmPage.razor.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/SignIn/SignInPanel.razor.cs(3 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/OfflineDatabaseDemoPage.razor.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/AuthManager.cs(0 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/HttpMessageHandlers/RequestHeadersDelegatingHandler.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Services/MauiDeviceCoordinator.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Diagnostics/DiagnosticsController.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.EmailConfirmation.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.PhoneConfirmation.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.ResetPassword.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.WebAuthn.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.cs(4 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/UserController.cs(3 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Mappers/IdentityMapper.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Models/Identity/UserSession.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Program.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/wwwroot/scripts/swagger-utils.js(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Program.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Services/ScssCompilerService.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IIdentityController.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IRoleManagementController.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IUserController.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/AppJsonContext.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/ConfirmEmailRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/ConfirmPhoneRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/EditUserRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/RefreshRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/SignInRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UserSessionDto.cs(0 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInDto.cs(0 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInRequestDto.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/IdentityJsonContext.cs(2 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Mapper.cs(1 hunks)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/AppPlatform.cs(3 hunks)
💤 Files with no reviewable changes (3)
- src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UserSessionDto.cs
- src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Services/AuthManager.cs
- src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInDto.cs
🧰 Additional context used
🧬 Code Graph Analysis (9)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IRoleManagementController.cs (2)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Management/RolesPage.razor.cs (16)
Task(33-48)Task(51-54)Task(56-71)Task(73-87)Task(89-120)Task(122-125)Task(127-137)Task(139-150)Task(152-163)Task(165-176)Task(178-199)Task(201-220)Task(222-252)Task(254-276)Task(278-310)Task(315-330)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UserRoleDto.cs (1)
UserRoleDto(3-8)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/IdentityJsonContext.cs (1)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs (1)
UpdateUserSessionRequestDto(3-19)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs (3)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Management/RolesPage.razor.cs (16)
Task(33-48)Task(51-54)Task(56-71)Task(73-87)Task(89-120)Task(122-125)Task(127-137)Task(139-150)Task(152-163)Task(165-176)Task(178-199)Task(201-220)Task(222-252)Task(254-276)Task(278-310)Task(315-330)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UserRoleDto.cs (1)
UserRoleDto(3-8)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedPubSubMessages.cs (1)
SignalREvents(20-36)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.ResetPassword.cs (1)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedPubSubMessages.cs (1)
SignalREvents(20-36)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Mappers/IdentityMapper.cs (2)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Mapper.cs (7)
Patch(31-31)Patch(34-34)Patch(35-35)Patch(37-37)Patch(38-38)Patch(39-39)Patch(41-41)src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Models/Identity/User.cs (1)
User(9-55)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/AppJsonContext.cs (1)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInRequestDto.cs (2)
VerifyWebAuthnAndSignInRequestDto(3-8)VerifyWebAuthnAndSignInRequestDto(10-13)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Mapper.cs (1)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Mappers/IdentityMapper.cs (4)
Patch(15-15)Patch(16-16)Patch(26-26)UserDto(13-13)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/SignIn/SignInPanel.razor.cs (1)
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInRequestDto.cs (2)
VerifyWebAuthnAndSignInRequestDto(3-8)VerifyWebAuthnAndSignInRequestDto(10-13)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.cs (2)
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Models/Identity/UserSession.cs (1)
UserSession(9-62)src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/SharedPubSubMessages.cs (1)
SignalREvents(20-36)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build and test
🔇 Additional comments (61)
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Maui/Services/MauiDeviceCoordinator.cs (1)
1-1: No concerns: BOM insertion only
The only modification is the addition of a Unicode Byte Order Mark (BOM) at the top of the file, which does not affect functionality or control flow.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.ResetPassword.cs (1)
65-65: LGTM! SignalR call standardization looks good.The addition of the
nullparameter aligns theSendAsyncmethod call with the standardized pattern used across other SignalR calls in the codebase. This maintains consistency without changing the functional behavior.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs (1)
1-19: Well-designed DTO for session management.The
UpdateUserSessionRequestDtoclass is well-structured with appropriate property types and helpful XML documentation. The use of theAppPlatformTypeenum forPlatformTypeprovides good type safety, and the nullable properties allow for flexible session updates.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Models/Identity/UserSession.cs (1)
51-61: Excellent addition of session tracking properties.The new properties (
PlatformType,CultureName,AppVersion) enhance session management capabilities with proper typing and clear documentation. These align well with theUpdateUserSessionRequestDtostructure.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Services/AppPlatform.cs (3)
29-32: Clarify Linux platform support status.The comment states "This is not supported yet in bit Boilerplate." Consider either implementing proper support or removing this property if it's not intended for use.
What's the intended timeline for Linux support? Should this property be marked as obsolete or removed until support is implemented?
45-53: Well-defined platform enumeration.The
AppPlatformTypeenum provides a clean, type-safe way to represent different platforms. The ordering and naming conventions are consistent.
12-18:❓ Verification inconclusive
Verify the platform detection behavior change.
The platform detection logic now requires
IsBlazorHybridto be true alongside the OS checks. This is a significant behavior change that could affect existing code relying on these properties.Please verify that this change is intentional and doesn't break existing platform detection logic:
🏁 Script executed:
#!/bin/bash # Search for usage of platform detection properties to assess impact rg -A 3 "AppPlatform\.(IsAndroid|IsIOS|IsWindows)" --type csLength of output: 5847
Confirm Intentional Change to Platform Detection Guard
Introducing theIsBlazorHybridrequirement inAppPlatform.IsAndroid/IsIOS/IsWindowsmeans these properties will now return false outside of Blazor Hybrid scenarios—this can alter existing behavior in multiple places:• Client/Boilerplate.Client.Maui/Services/MauiExternalNavigationService.cs (LaunchMode)
• Client/Boilerplate.Client.Maui/MauiProgram.cs (UseLocalNotification)
• Client/Boilerplate.Client.Maui/MauiProgram.Services.cs (EventLog)
• Client/Boilerplate.Client.Maui/Services/MauiLocalHttpServer.cs (browser-close and HTTP listener mode)
• Client/Boilerplate.Client.Core/Extensions/IConfigurationExtensions.cs (Android emulator address)
• Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/SessionsSection.razor.cs (push notifications)
• Client/Boilerplate.Client.Core/Components/Routes.razor.cs (routing on mobile)Please verify that restricting these checks to Blazor Hybrid is intentional and update the affected logic or documentation to avoid unintended breakages.
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/wwwroot/scripts/swagger-utils.js (2)
203-203: LGTM! DeviceInfo removal aligns with API refactoring.The removal of the
deviceInfoproperty from the sign-in request body is consistent with the broader refactoring that removesDeviceInfofrom identity-related DTOs across the codebase. This ensures the Swagger UI sign-in simulation matches the updated API contract.
203-203: LGTM! Consistent with session management refactor.The removal of
deviceInfofrom the sign-in request body aligns with the broader session management improvements mentioned in the PR. This ensures the Swagger UI simulation matches the updated API contract.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Program.cs (2)
31-31: LGTM! Improved platform detection using built-in .NET method.The change from
AppPlatform.IsWindowstoOperatingSystem.IsWindows()is a good improvement that uses the standard .NET platform detection method. This provides more reliable platform detection and aligns with similar changes across other server-side files.
31-31: Excellent improvement in platform detection.Replacing the custom
AppPlatform.IsWindowswith the built-inOperatingSystem.IsWindows()method is a good change that:
- Uses standard .NET APIs instead of custom implementations
- Reduces dependencies on custom platform detection logic
- Maintains the same functionality while improving maintainability
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.EmailConfirmation.cs (2)
63-63: LGTM! SignIn call updated consistently with DeviceInfo removal.The removal of the
DeviceInfoparameter from theSignInmethod call is consistent with the comprehensive refactoring that decouples device information from the sign-in confirmation process. This change aligns with similar updates across other identity controllers and the introduction of a dedicated session update mechanism.
63-63:✅ Verification successful
Good refactoring of session management.
Removing
DeviceInfofrom theSignIncall aligns with the session management improvements where device information is now handled separately through dedicated session update endpoints. This simplifies the email confirmation flow.Please verify that device information is properly captured elsewhere in the user flow, likely through the new
UpdateSessionendpoint mentioned in the AI summary:
🏁 Script executed:
#!/bin/bash # Description: Verify that UpdateSession endpoint exists and handles device info # Search for UpdateSession endpoint implementation ast-grep --pattern 'public async Task UpdateSession($$$)' # Search for UpdateUserSessionRequestDto to verify it includes DeviceInfo ast-grep --pattern 'class UpdateUserSessionRequestDto { $$$ }'Length of output: 126
🏁 Script executed:
#!/bin/bash # 1. Find any DTOs related to session updates rg "class .*Session.*Dto" -n src # 2. Look for any controller methods that handle session updates rg "Update.*Session" -n src # 3. Verify where DeviceInfo is still referenced rg "DeviceInfo" -n srcLength of output: 67737
🏁 Script executed:
#!/bin/bash # Verify that UpdateUserSessionRequestDto includes a DeviceInfo property grep -R "DeviceInfo" -n src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs || echo "No DeviceInfo property found"Length of output: 167
Session management refactor validated
DeviceInfo is no longer passed to SignIn but is captured in the dedicated session update flow:
- DTO: src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs defines
public string? DeviceInfo { get; set; }- API: IUserController.UpdateSession and UserController.UpdateSession(UpdateUserSessionRequestDto, …) handle the DTO
- Client: ClientAppCoordinator invokes UpdateSession with the same DTO
src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Web/Services/ScssCompilerService.cs (2)
19-19: LGTM! Consistent platform detection improvement.The change from
AppPlatform.IsWindowstoOperatingSystem.IsWindows()maintains consistency with similar platform detection improvements across the server-side codebase. Using the built-in .NET method provides more reliable platform detection for the SCSS compiler service.
19-19: Consistent platform detection improvement.Good change replacing custom
AppPlatform.IsWindowswith the built-inOperatingSystem.IsWindows()method. This is consistent with similar improvements across the codebase and uses standard .NET APIs for better maintainability. The pattern matching syntax withis falseis also a nice modern C# touch.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Program.cs (1)
19-19: LGTM! Good improvement using standard library.Replacing the custom
AppPlatform.IsWindowswith the built-inOperatingSystem.IsWindows()method is a solid improvement that leverages framework-provided functionality and reduces dependency on custom platform detection logic.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/ConfirmPage.razor.cs (2)
111-115: Consistent with email confirmation changes - good architecture.The
ConfirmPhonemethod correctly follows the same pattern as email confirmation, removingDeviceInfofrom the request while maintaining proper authentication flow.
81-85:✅ Verification successful
Approve the DeviceInfo removal - architectural improvement.
The removal of
DeviceInfofrom theConfirmEmailrequest is part of a well-architected refactor that separates authentication concerns from session metadata management. The authentication logic remains correct and focused.Verify that the new session management flow is properly implemented:
🏁 Script executed:
#!/bin/bash # Description: Verify the new UpdateUserSession mechanism is implemented # Expected: Find UpdateUserSession calls and UserController implementation echo "Searching for UpdateUserSession usage..." rg -A 5 "UpdateUserSession" echo "Searching for IUserController injection..." rg -A 3 "IUserController" echo "Searching for UpdateUserSessionRequestDto..." rg -A 10 "UpdateUserSessionRequestDto"Length of output: 26444
Session management flow is correctly implemented — approving DeviceInfo removal.
Verification confirms the new
UpdateUserSessionmechanism is in place and handles device metadata separately:
- ClientAppCoordinator.cs calls
await UpdateUserSession()and passesDeviceInfo,AppVersion, andPlatformType.IUserController.UpdateSession(UpdateUserSessionRequestDto…)is injected in client components.UpdateUserSessionRequestDtoincludesDeviceInfo,AppVersion, andPlatformType.- Server’s
UserController.UpdateSessionappliesrequest.DeviceInfo,request.AppVersion, andrequest.PlatformTypeto the user session.No further action required. Approving these architectural improvements.
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/SignInRequestDto.cs (1)
6-45:✅ Verification successful
Excellent architectural improvement - cleaner separation of concerns.
Removing
DeviceInfofromSignInRequestDtocreates a more focused DTO that handles only authentication-specific data. This improves single responsibility and aligns with the new session management architecture.Note: This is a breaking change for API consumers, but appears to be part of a coordinated refactor with proper migration path through the new session update mechanism.
Verify that server-side controllers have been updated consistently:
🏁 Script executed:
#!/bin/bash # Description: Check that IdentityController methods no longer expect DeviceInfo # Expected: No DeviceInfo usage in SignIn methods echo "Checking IdentityController SignIn methods..." rg -A 10 -B 5 "SignIn.*RequestDto" --type cs echo "Checking for any remaining DeviceInfo usage in identity controllers..." rg "DeviceInfo" --type cs | grep -i identityLength of output: 41544
DeviceInfo removal in SignIn endpoints confirmed
No references to
DeviceInforemain in anySignInRequestDto–based controller methods. The only remainingDeviceInfousages are in session‐management types (e.g.UserSessionDto,UpdateUserSessionRequestDto,UserSessionmodel), which aligns with the intended refactor.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/RefreshRequestDto.cs (1)
4-13:✅ Verification successful
Consistent completion of the DeviceInfo removal pattern.
The removal of
DeviceInfofromRefreshRequestDtomaintains consistency with other identity DTOs and completes the architectural improvement. The DTO is now properly focused on token refresh operations only.Verify that the refresh token flow has been updated consistently across client and server:
🏁 Script executed:
#!/bin/bash # Description: Check refresh token implementation consistency # Expected: No DeviceInfo in refresh flows, proper session update integration echo "Checking AuthManager refresh implementation..." rg -A 10 -B 5 "RefreshRequestDto" --type cs echo "Checking server-side refresh token handling..." rg -A 15 "RefreshToken.*async" --type cs echo "Verifying no remaining DeviceInfo in refresh flows..." rg "DeviceInfo.*[Rr]efresh|[Rr]efresh.*DeviceInfo" --type csLength of output: 8903
Confirmed DeviceInfo removal in refresh flows
All references to
DeviceInfohave been removed from the refresh token flow. TheRefreshRequestDtonow only includesRefreshTokenandElevatedAccessToken, and both the server-sideIdentityController.Refreshmethod and the sharedIIdentityController.Refreshsignature no longer referenceDeviceInfo.• Reviewed
IdentityController.cs– noDeviceInfoin theRefresh(RefreshRequestDto…)endpoint
• ReviewedIIdentityController.cs–Refresh(RefreshRequestDto…)signature is clean
• Ran global search forDeviceInfoin refresh flows – no matches foundApproving these changes.
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Management/RolesPage.razor.cs (2)
266-266: LGTM: Method rename improves clarity.The change from
ToggleUsertoToggleUserRolebetter describes the method's functionality of toggling a user's role assignment. This improves code readability and API clarity.
266-266: LGTM! Method name change improves clarity.The rename from
ToggleUsertoToggleUserRolemakes the method's purpose more explicit and aligns with the server-side API changes. The functionality and parameters remain unchanged.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/EditUserRequestDto.cs (2)
4-4: LGTM: Consistent naming convention improvement.The class rename from
EditUserDtotoEditUserRequestDtofollows the proper naming convention for request DTOs and improves clarity about the DTO's purpose. This aligns with the systematic refactoring mentioned in the summary.
4-4:✅ Verification successful
Verify consistent usage across the codebase.
The class rename from
EditUserDtotoEditUserRequestDtoimproves naming consistency by clearly indicating this is used for request data. Ensure all references to the old class name have been updated throughout the codebase.
🏁 Script executed:
#!/bin/bash # Description: Verify that all references to the old EditUserDto have been updated. # Expected: No remaining references to EditUserDto, only EditUserRequestDto should be found. echo "Searching for any remaining references to the old class name..." rg "EditUserDto" --type cs echo -e "\nSearching for new class name usage..." rg "EditUserRequestDto" --type cs -A 2Length of output: 4079
Verified consistent usage across codebase
No remaining references to
EditUserDtowere found; all occurrences have been updated toEditUserRequestDto. Approving the rename.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/ConfirmPhoneRequestDto.cs (2)
1-19: LGTM: Good architectural separation of device info from confirmation logic.The removal of the
DeviceInfoproperty from confirmation DTOs (as mentioned in the summary) represents a good architectural decision. Device information is better handled through dedicated session management mechanisms rather than being mixed with confirmation requests. This separation of concerns improves API clarity and maintainability.
1-19:✅ Verification successful
Approve the DeviceInfo property removal for better separation of concerns.
Removing the
DeviceInfoproperty fromConfirmPhoneRequestDtoimproves the architecture by separating phone confirmation logic from session/device management. The essential properties (PhoneNumberandToken) remain intact.Verify that device information is properly handled through the new session management mechanism:
🏁 Script executed:
#!/bin/bash # Description: Verify that UpdateUserSessionRequestDto exists and handles device information. # Expected: Find the new DTO and its usage in session management. echo "Searching for UpdateUserSessionRequestDto..." rg "UpdateUserSessionRequestDto" --type cs -A 5 echo -e "\nSearching for session update methods that might handle device info..." rg "UpdateSession|UpdateUserSession" --type cs -A 3Length of output: 9167
Approve DeviceInfo Removal and Confirm Session Handling
Verified that device information is now managed via
UpdateUserSessionRequestDtoand the session‐update endpoint:•
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/UpdateUserSessionRequestDto.cs
– Containspublic string? DeviceInfo { get; set; }alongsidePlatformType.
•src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/UserController.cs
–UpdateSession(UpdateUserSessionRequestDto request, …)updates.DeviceInfoon the user session.
•src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/ClientAppCoordinator.cs
– CallsuserController.UpdateSession(new() { DeviceInfo = TelemetryContext.Platform, … }).Since all session/device info flows through the new DTO and endpoint, the removal of
DeviceInfofromConfirmPhoneRequestDtois safe and improves separation of concerns.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.PhoneConfirmation.cs (1)
64-64:❓ Verification inconclusive
LGTM: DeviceInfo removal aligns with session management refactor.
The removal of
DeviceInfofrom theSignIncall is consistent with the broader refactor that centralizes device information handling through the new session update mechanism. This decouples device information from the phone confirmation flow, which improves separation of concerns.Please verify that the
SignInmethod signature has been updated to no longer expect theDeviceInfoparameter, and confirm that device information is properly captured through the newUpdateSessionendpoint.
🏁 Script executed:
#!/bin/bash # Description: Verify SignIn method signature and UpdateSession endpoint implementation # Expected: SignIn method should not have DeviceInfo parameter, UpdateSession should exist # Check SignIn method signature ast-grep --pattern 'SignIn($$$) { $$$ }' # Check for UpdateSession endpoint rg -A 10 "UpdateSession"Length of output: 5063
Approve: DeviceInfo removal aligns with session management refactor
The removal of
DeviceInfofrom theSignIncall is intentional and aligns with the new centralized session update flow. We’ve verified that theUpdateSessionendpoint exists inIUserControllerand is implemented inUserController, correctly updatingDeviceInfo,AppVersion,PlatformType, andCultureName.• Please confirm that the
SignInmethod signature has been updated to no longer expect aDeviceInfoparameter.
• Ensure that all device information is now captured exclusively via theUpdateSessionendpoint.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/OfflineDatabaseDemoPage.razor.cs (1)
14-14:✅ Verification successful
LGTM: DTO type rename for consistency.
The change from
EditUserDtotoEditUserRequestDtoaligns with the broader DTO naming convention updates across the codebase. This improves consistency in the naming patterns for request DTOs.Please verify that
EditUserRequestDtoexists and has all the required properties that were present inEditUserDtoto ensure compatibility.
🏁 Script executed:
#!/bin/bash # Description: Verify EditUserRequestDto exists and compare with usage patterns # Expected: EditUserRequestDto should be defined and used consistently # Check if EditUserRequestDto is defined ast-grep --pattern 'class EditUserRequestDto { $$$ }' # Check usage patterns across the codebase rg "EditUserRequestDto" -A 3 -B 3Length of output: 8349
Verified: DTO rename is consistent and complete.
Confirmed that
EditUserRequestDtois defined in
• src/Shared/Dtos/Identity/EditUserRequestDto.cs
and that all formerEditUserDtousages have been updated—mapping extensions, controllers, JSON context, and component code. No missing members detected; the rename is safe to merge.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IRoleManagementController.cs (1)
40-40: LGTM: Method rename improves API clarity.Renaming
ToggleUsertoToggleUserRolesignificantly improves the API's clarity by making it explicit that this method toggles a user's role assignment rather than the user entity itself. This is a well-designed change that enhances the method's semantic meaning.The relevant code snippets confirm that the client-side code in
RolesPage.razor.cshas been updated accordingly to useToggleUserRole, ensuring consistency across the interface and implementation.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/ConfirmEmailRequestDto.cs (1)
1-20:✅ Verification successful
LGTM: DeviceInfo removal improves separation of concerns.
The removal of the
DeviceInfoproperty fromConfirmEmailRequestDtois a positive change that improves separation of concerns. The DTO now focuses solely on email confirmation requirements (Token), while device information is handled through the centralized session update mechanism.The inheritance relationship with
ChangeEmailRequestDtois preserved, maintaining consistency in the email-related confirmation flows.Please verify that device information is properly captured and updated through the new
UpdateUserSessionRequestDtoandUpdateSessionendpoint after email confirmation.
🏁 Script executed:
#!/bin/bash # Description: Verify the new session update mechanism handles device info properly # Expected: UpdateUserSessionRequestDto should include DeviceInfo, UpdateSession endpoint should exist # Check UpdateUserSessionRequestDto definition ast-grep --pattern 'class UpdateUserSessionRequestDto { $$$ }' # Check if DeviceInfo is included in the new DTO rg "DeviceInfo" --type cs -A 3 -B 3 # Verify UpdateSession endpoint usage in client code rg "UpdateSession" --type cs -A 5Length of output: 20100
Approve: Email confirmation DTO and session update integration verified
The
ConfirmEmailRequestDtocleanly focuses onToken, and device information is now correctly handled via the new session update mechanism:
UpdateUserSessionRequestDtoinsrc/Shared/Dtos/Identity/UpdateUserSessionRequestDto.csincludes aDeviceInfoproperty.- The
UserController.UpdateSession(UpdateUserSessionRequestDto…)endpoint exists and calls
.SetProperty(x => x.DeviceInfo, request.DeviceInfo), ensuring device info is persisted.- The inheritance of
ChangeEmailRequestDtofromConfirmEmailRequestDtoremains valid and consistent.All concerns have been addressed—no further action required.
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/AppJsonContext.cs (1)
60-60: LGTM: JSON serialization context updated correctly.The JSON serialization attribute has been properly updated to reference the renamed DTO
VerifyWebAuthnAndSignInRequestDto, which aligns with the broader refactoring effort.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/IdentityJsonContext.cs (2)
17-17: LGTM: JSON serialization updated for renamed DTO.The serialization attribute has been correctly updated from
EditUserDtotoEditUserRequestDto, maintaining consistency with the DTO renaming throughout the codebase.
34-34: LGTM: New session management DTO properly added.The addition of
UpdateUserSessionRequestDtoto the JSON serialization context supports the new user session management functionality introduced in this PR.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Identity/SignIn/SignInPanel.razor.cs (3)
119-123: LGTM: WebAuthn DTO updated correctly.The code has been properly updated to use
VerifyWebAuthnAndSignInRequestDtoinstead of the old DTO. The property assignments (ClientResponseandTfaCode) match the new DTO structure as shown in the relevant code snippets.
155-156: LGTM: DeviceInfo removal aligns with session management refactoring.The removal of
DeviceInfoassignment is consistent with the broader refactoring that separates device information handling from sign-in requests to dedicated session management.
165-166: LGTM: DeviceInfo removal consistent with refactoring.Similar to the email confirmation, the removal of
DeviceInfofrom phone confirmation aligns with the new session management approach.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Mappers/IdentityMapper.cs (1)
16-16: LGTM: Mapper method updated for renamed DTO.The
Patchmethod signature has been correctly updated to useEditUserRequestDtoinstead ofEditUserDto, maintaining consistency with the DTO renaming throughout the codebase. The method continues to properly map from the request DTO to theUserentity.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/ProfileSection.razor.cs (2)
20-20:✅ Verification successful
LGTM! DTO type change for consistency.
The change from
EditUserDtotoEditUserRequestDtoaligns with the broader refactoring effort mentioned in the AI summary. This appears to be a naming consistency improvement.Please verify that
EditUserRequestDtohas the same properties and structure as the previousEditUserDtoto ensure compatibility:
🏁 Script executed:
#!/bin/bash # Description: Verify EditUserRequestDto exists and compare with any remaining EditUserDto references # Search for EditUserRequestDto definition ast-grep --pattern 'class EditUserRequestDto { $$$ }' # Search for any remaining EditUserDto references that might need updating rg "EditUserDto" -A 3 -B 3Length of output: 84
Let’s locate and compare both DTOs more reliably:
This will confirm that
EditUserRequestDtoexists (and locate its file) and ensure there are no strayEditUserDtousages.
🏁 Script executed:
#!/bin/bash set -e echo "🔍 Searching for EditUserRequestDto declarations..." rg -n "class EditUserRequestDto" || rg -n "record EditUserRequestDto" || rg -n "interface EditUserRequestDto" echo echo "🔍 Searching for files named *EditUserRequestDto*.cs..." fd -e cs "EditUserRequestDto" echo echo "🔍 Searching for any remaining EditUserDto references..." rg -n "EditUserDto"Length of output: 686
Approve: DTO rename verified
- Confirmed
EditUserRequestDtois declared in
src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/EditUserRequestDto.cs- No remaining
EditUserDtoreferences in the codebaseLGTM—merging this consistency-driven rename.
20-20: LGTM: Consistent DTO type refactoring.The change from
EditUserDtotoEditUserRequestDtoaligns with the broader refactoring effort across the codebase to improve DTO naming consistency. The functionality remains unchanged.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IIdentityController.cs (2)
56-56:✅ Verification successful
DTO parameter type updated for consistency.
The change from
VerifyWebAuthnAndSignInDtotoVerifyWebAuthnAndSignInRequestDtomaintains consistency with the broader DTO naming refactoring effort.Please verify that all implementations of this interface method have been updated to use the new DTO type:
🏁 Script executed:
#!/bin/bash # Description: Verify all implementations use the new DTO type and check for any remaining old references # Search for implementations of VerifyWebAuthAndSignIn method ast-grep --pattern 'VerifyWebAuthAndSignIn($_, $_) { $$$ }' # Search for any remaining references to the old DTO rg "VerifyWebAuthnAndSignInDto" -A 2 -B 2 # Search for usage of DeviceInfo in WebAuthn context since AI summary mentions its removal rg "DeviceInfo" --type cs -A 2 -B 2Length of output: 12807
IIdentityController – DTO rename verified, no dangling references
All occurrences of the oldVerifyWebAuthnAndSignInDtohave been removed; there are no remaining references in the codebase. Implementations callingVerifyWebAuthAndSignInwill fail to compile if not updated, so any missed changes will be caught at build time. No further action needed.
56-56: LGTM: Consistent DTO refactoring aligned with DeviceInfo removal.The change from
VerifyWebAuthnAndSignInDtotoVerifyWebAuthnAndSignInRequestDtois part of the broader refactoring effort that removes theDeviceInfoproperty from identity-related DTOs. This aligns with the new session management approach introduced in this PR.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/RoleManagementController.cs (2)
158-158: LGTM! Method naming improvement.The rename from
ToggleUsertoToggleUserRoleprovides better semantic clarity about the method's purpose - toggling a user's role assignment rather than toggling the user themselves.
214-214: LGTM! Enhanced SignalR messaging with page URL context.The conditional inclusion of
pageUrlin the SignalR message payload is a good enhancement that allows clients to navigate to specific pages when handling notifications, while maintaining backward compatibility by passingnullwhen no page URL is provided.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.WebAuthn.cs (2)
60-60: LGTM! DTO type update aligns with session management refactoring.The change from
VerifyWebAuthnAndSignInDtotoVerifyWebAuthnAndSignInRequestDtois consistent with the broader refactoring effort to improve session management and removeDeviceInfofrom authentication request DTOs.
76-76: LGTM! Consistent with new session management approach.The removal of
DeviceInfofrom theSignIncall aligns with the new architecture where session information is managed separately through dedicated endpoints rather than being included in authentication requests.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Dtos/Identity/VerifyWebAuthnAndSignInRequestDto.cs (1)
3-13: LGTM! Well-designed DTO with improved session management.The new DTO design demonstrates several best practices:
- Generic design:
VerifyWebAuthnAndSignInRequestDto<T>provides type safety for different client response types- Required property:
ClientResponseuses therequiredkeyword ensuring it's always provided- Convenience class: The non-generic subclass with
JsonElementprovides a default specialization- Clean separation: Removal of
DeviceInfoaligns with the new session management architecturesrc/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Controllers/Identity/IUserController.cs (2)
20-21: LGTM! New session management endpoint enhances architecture.The addition of the
UpdateSessionmethod provides a dedicated endpoint for managing session properties likeAppVersion,DeviceInfo,PlatformType, andCultureName. This separation of session management from authentication flows is a good architectural improvement.
24-24: LGTM! DTO naming consistency improvement.The change from
EditUserDtotoEditUserRequestDtoimproves naming consistency by using the "RequestDto" suffix for DTOs used in API requests, making the codebase more maintainable and semantically clear.src/Templates/Boilerplate/Bit.Boilerplate/src/Shared/Mapper.cs (1)
38-39: LGTM! Consistent with the DTO renaming.The method signatures have been correctly updated to use
EditUserRequestDtoinstead ofEditUserDto, aligning with the DTO renaming across the codebase.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/IdentityController.cs (4)
104-104: LGTM! Consistent with session management refactor.The removal of the
deviceInfoparameter aligns with the new approach where session properties are updated through the dedicatedUpdateSessionendpoint.
189-189: Method signature correctly updated.The
CreateUserSessionmethod signature has been properly updated to remove thedeviceInfoparameter, consistent with the new session management approach.
412-412: Consistent SignalR update.The
nullparameter addition is consistent with the SignalR method signature changes throughout the codebase.
343-343:✅ Verification successful
SignalR call updated correctly.
The addition of
nullas the third parameter aligns with the updated SignalR method signature that now supports an optional data payload.Let me verify the SignalR
SendAsyncmethod signature to confirm this change is correct:
🏁 Script executed:
#!/bin/bash # Search for other SendAsync calls to understand the pattern rg -A 2 -B 2 "SendAsync.*SignalREvents\.(SHOW_MESSAGE|PUBLISH_MESSAGE)" --type csLength of output: 11906
Confirm SignalR SendAsync overload usage
The added
nullthird argument matches the updated SendAsync signature and aligns with existing calls across controllers—no changes needed.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Identity/UserController.cs (4)
97-108: Well-implemented session update endpoint.The
UpdateSessionmethod efficiently updates session properties usingExecuteUpdateAsync. Good practices observed:
- Atomic update of all properties
- Proper session scoping with
User.GetSessionId()- Appropriate error handling when session not found
111-111: Parameter type correctly updated.The method parameter has been updated to use
EditUserRequestDto, consistent with the DTO renaming throughout the codebase.
432-432: SignalR call updated consistently.The addition of
nullparameter aligns with the updated SignalR method signature.
465-465: Consistent SignalR update.The
nullparameter addition is consistent with other SignalR calls.src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/ClientAppCoordinator.cs (2)
179-201: SignalR handler correctly updated for new signature.The handler now properly:
- Accepts the additional data payload parameter
- Returns
falsewhen unable to display data (SnackBar limitation)- Returns
truewhen message is successfully shown- Includes data in the notification when available
273-282: Well-implemented session update method.The implementation correctly:
- Collects all required telemetry data
- Handles culture name based on
InvariantGlobalizationsetting- Uses the current cancellation token for proper cancellation support
src/Templates/Boilerplate/Bit.Boilerplate/src/Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/SessionsSection.razor.cs (1)
130-130:✅ Verification successful
Verify the updated platform detection logic.
The simplified condition
AppPlatform.IsWindows is falseassumes thatIsWindowsnow internally requires a BlazorHybrid context. This simplification improves code readability.Please verify that the platform detection logic works as expected by checking the
AppPlatform.IsWindowsimplementation:
🏁 Script executed:
#!/bin/bash # Description: Check the implementation of AppPlatform.IsWindows to confirm it includes BlazorHybrid check. # Expected: The property should internally check for BlazorHybrid context. echo "Searching for AppPlatform class and IsWindows property implementation..." ast-grep --pattern 'class AppPlatform { $$$ }' echo -e "\nSearching for IsWindows property specifically..." rg "IsWindows" --type cs -A 3 -B 1Length of output: 10550
Confirming
IsWindowsincludes BlazorHybrid guard
TheAppPlatform.IsWindowsproperty is implemented aspublic static bool IsWindows => IsBlazorHybrid && OperatingSystem.IsWindows();in
src/Shared/Services/AppPlatform.cs, so usingif (AppPlatform.IsWindows is false)correctly replaces the previous
IsBlazorHybrid+IsWindowscheck.src/Templates/Boilerplate/Bit.Boilerplate/src/Server/Boilerplate.Server.Api/Controllers/Diagnostics/DiagnosticsController.cs (1)
61-61: Good enhancement: Structured SignalR message with contextual data.The updated SignalR message now includes structured data (pageUrl and action) that aligns with the push notification format on line 54, providing consistency between different notification channels and making the message more actionable for clients.
...Client/Boilerplate.Client.Core/Components/Pages/Authorized/Settings/SessionsSection.razor.cs
Show resolved
Hide resolved
...ilerplate/src/Server/Boilerplate.Server.Api/Controllers/Diagnostics/DiagnosticsController.cs
Show resolved
Hide resolved
1 participant
closes #10894
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
API Changes
Chores