Ability to change baseurl

christallire commented 1 year ago

Description

Hey guys,

This is related to https://github.com/dotnet/aspnetcore/issues/35077 and I'm having a similar problem. and yes, this is a blocker for many use cases many people posted.

I'm suggesting an alternative solution: ability to change the base URL and let users choose to traffic fall through when base URL interception is not hit.

Public API Changes

Need to expose and give the ability to change outside of framework somehow:

https://github.com/dotnet/maui/blob/d0e903735c141cc5ce1f6a07a2265cfb0f8da3c3/src/BlazorWebView/src/Maui/BlazorWebView.cs#L11-L13

https://github.com/dotnet/maui/blob/ff3e934de281ef241f84f85fa6c2825b390d732e/src/BlazorWebView/src/SharedSource/WebView2WebViewManager.cs#L50-L60

on a side note: this won't make requests substantially faster because there's will be no DNS resolution as long as we intercept. and even if they do resolution will be cached so this will be premature optimization, don't they?

Intended Use-Case

So similar to this issue (https://github.com/dotnet/aspnetcore/issues/35077)

example baseurl: contoso.com

case 1 1) app start 2) app shows the initial page 3) app trying to send ajax POST to contoso.com/some-api (not working, we need a server or fall through to browser request instead of injection) 4) app continues to run
case 2 1) app start 2) app shows the initial page 3) user input, app trying to redirect to a dynamic page with the same domain which only available via the server 4) server redirects the user back to the original page

This is important because users shouldn't alter their entire architecture because MAUI is not supporting it.

ghost commented 1 year ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

Eilon commented 1 year ago

We initially chose 0.0.0.0 for two reasons:

It's never a valid address, so it can't be confused with any "real" web site or address
There is never any overhead for DNS resolution because it's already an IP address. In an initial investigation we noticed some perf cost due to DNS resolution when a "fake" hostname was used, for example, https://fakeapp/. We would need to check if that's still an issue on any platform before making any feature like this (because if there still is a DNS cost, it's not a solution we'd want anyone to use).

christallire commented 1 year ago

Thanks for the explanation. I think this is crucial for anyone who wants to use blazor hybrid especially have their own blazor webassembly app already: There's no choice except change my architecture or include asp.net kestrel assembly in our app like this (https://github.com/dotnet/aspnetcore/issues/35077#issuecomment-1327930590)

I think this is still a quick escape hatch anyone would use rather than blocking issue

Bohdandn commented 1 year ago

One more use case: Since 0.0.0.0 is not considered as secure context by some old web views you get limited access to browser api via JS. Cordova allows changing is via hostname property in config.xml.

Example: iOS 14.5

if app origin: app://0.0.0.0/
windows.isSecureContext == false
navigator.mediaDevices == null

if app origin: app://localhost/
windows.isSecureContext == true
navigator.mediaDevices - has value, media devices accessible

It works on iOS 16.3 but we need to be backward compatible, iOS 14.X is still 6-14% of iOS market. So I'd make it configurable and default to 0.0.0.0. https://bugs.webkit.org/show_bug.cgi?id=220184

You can use WebRTC native libraries to get media devices but it doesn't work on iOS because of bindings issue + it's not fully hybrid approach (we have blazor wasm app as well). So @christallire the only workaround so far is:

var handlerType = typeof(BlazorWebViewHandler);
var field = handlerType.GetField("AppOriginUri", BindingFlags.Static | BindingFlags.NonPublic) ?? throw new Exception("AppOriginUri field not found");
field.SetValue(null, new Uri("app://localhost/"));

christallire commented 1 year ago

@Bohdandn thanks for the workaround. I was about to try WebRTC too! it would save a ton of time.

One funny thing is that it renders clarity (from Microsoft) unusable too.

UweKeim commented 4 months ago

I'm having several Windows apps which are widely used publicly since years, that fire up ad hoc local app-built-in web servers at http://127.0.0.1:<RandomPort>.

Using some code to determine a free port (see attached file as an example) and then start my web server at http://127.0.0.1:<Port> works totally fine.

So such an URL would be e.g. http://127.0.0.1:9218. I never had any collisions or errors, even when including other iframes like YouTube or other popular services.

Suggestion

So my suggestion would be to also use 127.0.0.1 together with a mandatory, random non-80 port. And make both the IP address and the port optionally configurable from outside to match all scenarios developers might encounter in their special case.

dotnet / maui