Replies: 1 comment 1 reply
-
You should be able to start blazor manually and passing the environment there via JavaScript. Example: <script src="_framework/blazor.webassembly.js" autostart="false"></script>
<script>
Blazor.start({
environment: document.domain.includes("dev.") ? "Staging" : "Production"
});
</script> Related issue #20935 and PR #24031 Looks like this isn't documented in either https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0 or https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/environments?view=aspnetcore-5.0 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In asp.net core it's trivial to configure an application differently for each environment, not so much in Blazor wasm.
If I'm not missing anything, the current (3.2) version relies on reading an http header called Blazor-Environment and if that's null it defaults to Production.
Setting the aforementioned header is hard/impossible when using static storage options for Blazor, I'm thinking for example at Static website hosting in Azure Storage since we don't have any options to configure the web server in front of the storage.
My specific need is to configure OIDC related properties differently for each environment, e.g. staging app should use staging identity provider and production app one should use the production identity provider and so on.
Describe the solution you'd like
Option 1
It would be nice to be able to opt-in and override the default behavior of calculating the environment, one idea that came to my mind was to switch on the current BaseAddress to calculate the environment since different application environments will be hosted in different places (domain).
I was thinking about the ability to implement a custom interface and pass an instance in the
WebAssemblyHostBuilder.CreateDefault(args, new MyCustomEnvironmentSelector())
where the interface may looks like the following:
and the default behavior will be the actual one.
Option 2
Another option I was thinking about is the ability to specify the environment in the blazor.boot.json at publish time and read that value when the Blazor-Environment header is missing (not sure if it's too late already here)
Execute something like this at publish time
dotnet publish -c Release /p:environment=Staging
and store the value (Staging) in the blazor.boot.json so it can be read at runtime.
What do you think about this?
Beta Was this translation helpful? Give feedback.
All reactions