Description
#28017
In 5.0.1 we fixed a publish scenario where Blazor webassembly wasn't respecting the StaticWebAssetBasePath defined for the project. Unfortunately the logic for handling the path composition was not robust enough and while it fixed the publish output layout, it introduced an integration issue later on at runtime.
The current fix makes the handling of the path more tolerant to initial and final slashes and includes a new end to end test that validates this scenario.
Customer Impact
Customers can't host blazor applications outside the root path (/)
Regression?
Yes. Worked in 3.2
Risk
Low.
We've included additional tests and E2E automation to verify this case.
Validation
Automated
Manual
Description
In 5.0 we introduced two features on Blazor routing that enable users to write routing templates that match paths with variable length segments. These two features are optional parameters {parameter?} and catch all parameters {*catchall}.
Our routing system ordered the routes based on precedence and the (now false) assumption that route templates would only match paths with an equal number of segments.
The implementation that we have worked for naïve scenarios but breaks on more real world scenarios. The change here includes fixes to the way we order the routes in the route table to match the expectations as well as fixes on the route matching algorithm to ensure we match routes with variable number of segments correctly.
Customer Impact
This was reported by customers on #27250
The impact is that a route with {*catchall} will prevent more specific routes like /page/{parameter} from being accessible.
There are no workarounds since precedence is a fundamental behavior of the routing system.
Regression?
No, these Blazor features were initially added in 5.0.
Risk
Low. These two features were just introduced in 5.0 and their usage is not as prevalent as in asp.net core routing. That said, it's important to fix them as otherwise we run the risk of diverting in behavior from asp.net core routing and Blazor routing, which is not something we want to do.
We have functional tests covering the area and we've added a significant amount of unit tests to validate the changes.
* Attempt to read the logs from the browser
Seleniunm currently does not return log messages (See https://github.com/SeleniumHQ/selenium/issues/8229).
This making figuring out blazor WASM test failures a lot harder.
This change adds some JS to the test apps to read the console output.
* WIP
* Updates to IdentityServer 4.0.4
* Updates templates with the new migrations.
* Fixes a small configuration bug that required the configuration for the key to be specified.
* Updates the error url in IdentityServer config to match our template defaults.
* Use BlazorWebAssemblySDK
* Update projects to use the BlazorSDK
* Remove tasks and targets from RazorSDK
* Remove workarounds from BlazorSDK
* Fixup
* Fixup
* nit: Remove useless `$(HasReferenceAssembly)` settings
- set in /Directory.Build.targets
- `true` only in `$(IsAspNetCoreApp)` projects
* nit: Remove useless `$(CompileUsingReferenceAssemblies)` settings
- no current versioning differences between ref/ and src/ assemblies when targeting default TFM
* Add more `$(GenerateDocumentationFile)` settings
- increases the number of generated doc files, mostly without problems
- !fixup! correct typo in `DebugProxyHost` doc comments
- was not generating a doc file before
- remove previous (ineffective) src/Components/Directory.Build.targets setting
- nit: remove a duplicate `$(GenerateDocumentationFile)` setting
* nit: Remove useless `$(IsPackable)` settings
- only analyzers and implementation projects are packable by default
- main use case for explicit setting is projects shipping only in shared framework
- conditional setting in src/Mvc/Directory.Build.props just subset logic in /Directory.Build.targets
* nit: Remove useless `$(IsProjectReferenceProvider)` settings
- only implementation projects are providers by default
* nit: Remove useless `$(IsTestAssetProject)` settings
- set in src/Mvc/test/WebSites/Directory.Build.props
* !fixup! Looks like `InProcessNewShimWebSite` must compile w/o ref/ assemblies
- restore `$(CompileUsingReferenceAssemblies)` in this one project
* Undo overzealous merge choices
* Undo temporary changes applied when part of the repo was building in the blazor-wasm branch
* Skip SPA template tests in 3.1
* Fixup reference to Microsoft.AspNetCore.Components.WebAssembly.HttpHandler
As part of attempting to fix the reference in the test project (which ultimately wasn't needed), I messed up the package reference in the WebAssembly package
This fixes the package reference and removes unnecessary code from the test project
* Adds an authorization handler for integration with HttpClient in different scnearios.
* Adds a message handler to streamline calling protected resources on the same base address.
* UserFactory->AccountClaimsPrincipalFactory
* Change constants to static readonly
* Make applicationpaths provider and RemoteAuthenticatorViewCore dependencies internal
* Change collection types, make properties get only where possible
* Change state constraint to extend RemoteAuthenticationState
* Avoid using query parameter when passing messages to the error UI.
* Adds an additional parameter to automatically perform the redirect.
* Fix provisioning additional tokens in MACWA.
* Fix create solution with spaces
* Cleanup Msal startup APIs.
* Rename UserFactory -> AccountClaimsPrincipalFactory
* Introduces customization options for mapping user claims principals.
* Supports login/logout flows extensibility.
* Improves E2E test reliability
* Improves reliability on the AuthenticationService
* Improves the experience by trying to silently log-in users on startup.
* Avoids loading the Blazor application when within a hidden iframe.
* Adds MetadataAddress property to OidcProviderOptions.
* Sets defaults for the Msal cache location on the provider initialization.
* Updates the template to avoid redirecting to the login page if the user is already authenticated.
* Fixes startup APIs for AddRemoteAuthentication.
* Fixes TryGetToken for the Blazor MSAL library when the token can't be acquired silently.
* In debug mode, don't enable the linker by default
* Fixup
* Update Blazor.MonoRuntime.targets
* Ensure we have a true/false value. Stop inferring from BlazorLinkOnBuild.
* Avoid doing work for ServiceWorkerAssetsManifest when it's not being used
* React to BlazorLinkOnBuild->BlazorWebAssemblyEnableLinking rename
Co-authored-by: Pranav K <prkrishn@hotmail.com>
* Support logging errors that happen really early
* Tolerate all the ways caching might be unavailable
* Include dotnet.js in blazor.boot.json
* Reorganize boot manifest to categorize files by role, not just by filename extension
* Enable cache-busting and SRI check on dotnet.js
* Change cache-busting to vary filename, not using querystring. Needed to make PWA manifest still work.
* [Blazor] Move Blazor to use Static Web Assets
* Plugs-in Blazor wasm through the static web assets infrastructure.
* Avoids the need for a custom Blazor.config file.
* Removes broken auto-rebuild and debug support.
* Removes unnecessary server-side Blazor helpers.
Javier Calvarro Nelson
Pranav K
Safia Abdalla
Ajay Bhargav B
Doug Bunting
dotnet-maestro[bot]
Steve Sanderson
Marlon Regenhardt