.NET 5 with new Blazor is out

[sorainnosia]

Any chance for this project to get updated to .NET 5.0?

Thank you

[Daddoon]

I have a lot of work in November and December, that's also why i didn't get back on the project sooner. Also, another reason is that since Mobile Blazor Bindings project from Microsoft now support Hybrid Blazor app in Xamarin, i think this project is less essential.

I remember that some things are missing on Mobile Blazor Bindings the last time i checked, like the possibility to share the same kind of project in order to reuse it on web and mobile at the same time without any tricks, or something like that. But i didn't rechecked since.

Is something missing on Mobile Blazor Bindings that you need and was on BlazorMobile ?

[sorainnosia]

Blazor Mobile Binding do not have Electron project.

And if I am not wrong the client wasm project (mono wasm) can't be reused in mobile (android/iOS) project

Also the project is experimental, even though it has fancy xamarin/html combination

I think they Intentionally include razor with xamarin for mobile to focus on mobile leaving out pure wasm option. But what I need is simple wasm page that can be reuse across all platfkrm

[Daddoon]

Blazor Mobile Binding do not have Electron project.

Yes, and it was not their goal. As Steve Sanderson said some month ago (maybe a year ?) one of their implementation goal was to be able to ship Blazor launchable with the minimal components needed, in order to have very tiny build size while doing some kind of Blazor Desktop apps.

But by the way, i think you can already use Blazor with Electron without BlazorMobile, there is a few things to do to, but nothing that i didn't already use in BlazorMobile. But yes of course you would not have the BlazorMobile layer that is shared between platforms on this project. It depends your requirements.

And if I am not wrong the client wasm project (mono wasm) can't be reused in mobile (android/iOS) project

As far as i know, the actual Hybrid of Microsoft don't use the WASM mode, so i suspect some kind of Server-side (on your device Native) with WebSockets. This mean the rendering is powered by a native C# engine, the one of your device. See the doc here .

An interesting reading here: https://github.com/xamarin/MobileBlazorBindings/issues/155

Also the project is experimental, even though it has fancy xamarin/html combination

Yes, but never forget it's powered by Microsoft, and me i'm nearly the one on this project except some thankful contributions. And by myself i canno't be always on the open source projects, so it's harder to keep in line.

I think they Intentionally include razor with xamarin for mobile to focus on mobile leaving out pure wasm option. But what I need is simple wasm page that can be reuse across all platfkrm

You may find a solution on the previous link i posted. But otherwise if you are out of luck (like for Electron) with the posted links, keep me updated. I will try to take a look at the end of the month if i'm able to unlock some times.

[jspuij]

It is possible to create an MBB project that targets all MBB platforms, as well as WASM/Server. MBB requires you to move your Blazor WebUI into a separate project (called a Razor Class Library) that can be shared across all platforms. Based on the feedback here and in the MBB repo we will create starter templates for those.

https://github.com/xamarin/MobileBlazorBindings/issues/238

Of course you would not be able to use native mobile components in the WASM/SSB variant of your application, but as long as you stick to HTML, Blazor and CSS, you will be able to use a single UI across:

• iOS (and iPadOS)
• macOS
• Android
• Windows (.net core and wpf)
• Webassembly
• Server Side Blazor

regarding Linux: as soon as we add support for a GTK+ webview, this would be possible. It will require fixing libwebkit inside Xamarin first though: https://github.com/xamarin/Xamarin.Forms/issues/3571. I'm not sure I'm willing to take on this maintenance for such a small user base and this being a preview and me being a volunteer contributor. And I think @Eilon won't want to start supporting linux atm.

regarding UWP: as long as CoreRT does not support netstandard2.1, it does not make sense to try and target the platform. SSB and BlazorWebassembly (the 3.2 version that came after .net core 3.1 LTS) target netstandard 2.1 (although webassembly previews and the first SSB version of Blazor targeted netstandard 2.0). So if you want to target an LTS .net release of Blazor, you need netstandard 2.1. You are better off running the WASM version then inside a browser. I don't think UWP is particularly interesting as target anymore as windows phone is dead and windows ARM tablets / notebooks are few and far between. ARM tablets / notebooks probably will be able to run a .net core MBB application with the ARM64 WebView2 SDK although I haven't tried it. That leaves the XBOX that you won't be able to target with MBB at the moment.

Regarding the technology: MBB hybrid apps run on a native runtime (being either .net core or mono, depending on platform) and use a webview to display blazor content. There is no webserver, just an Http handler directly attached to the webview that intercepts load requests and serves content. The JS interop is similar to webassembly (it does not use SignalR) but directly uses the javascript <-> .NET bridges that all webviews provide.

You do get a full performance, multi-threaded runtime however with support for native device features access (through Xamarin Essentials or the .NET api).

[Daddoon]

@jspuij Thanks for this extensive review !

So mainly, if i understand, there is no things that Mobile Blazor Bindings and other various templates cannot do compared to BlazorMobile (created 2 years ago).

Still wondering how the Javascript / .Net Bridge is working under the hood, as would not this be considered a security flaw by some companies like Apple ? But i'm surely missing the points here, as i doesn't have taken a look on it.

[jspuij]

Don't expect too much of the JS interface. Sending messages is usually done using EvaluateJavascript and all webviews provide functionality to receive strings from a script. E.g for iOS:

send:

https://github.com/xamarin/MobileBlazorBindings/blob/master/src/Microsoft.MobileBlazorBindings.WebView.iOS/WebViewExtendedWKWebViewRenderer.cs#L105-L109

receive:

https://github.com/xamarin/MobileBlazorBindings/blob/master/src/Microsoft.MobileBlazorBindings.WebView.iOS/WebViewExtendedWKWebViewRenderer.cs#L158-L166

And you are correct in your assumption that Apple regards an embedded webview as insecure: It does not share cookies with the main browser, it won't be allowed to run password managers and don't try to do Auth (oauth/openid) with it, as the return URLs are usually blocked (there are some hacks around that, but still). So we will be leveraging the OS primitives for Auth in the next release of MBB to provide authentication that works similarly to webassembly, but uses a secure os webview (or custom tab on Android) to auth. This secure webview does not do javascript interop, shares cookies with the main browser, and will handle capture of the return URL for you.

[sorainnosia]

Hi jspuij

I am not very familiar with webview.

Correct me if I am wrong, when for example we make a mobile app based on blazor client wasm, the app itself need to have full webview as its main control?

Then the webview render pages based on html in razor pages, is this correct?

But for cases like MBB, is the main app a full page webview?

Then for xamarin and blazor hybrid it has native UI control, highlikely the app is not webview but will auto add a webview when the component is Html razor pages but when the developer uses native UI it will include a native component?

In such case, the app is a mixed between native component with 1 or more webview?

But I have a requirement to get cookies from a component webview. The component load a page and user sign in to the site. It then get the cookies.

The app interact with the site using the stored cookies and display content.

Android allows app to get cookies from its webview component as long as the component is loaded by an app. Somewhere in between.

For Blazor which render as wasm and run in as one or more webview component on an app, can the webview and the app communicate to pass cookies or header?

Thank you

[Daddoon]

Hi jspuij

I am not very familiar with webview.

Correct me if I am wrong, when for example we make a mobile app based on blazor client wasm, the app itself need to have full webview as its main control?

Then the webview render pages based on html in razor pages, is this correct?

But for cases like MBB, is the main app a full page webview?

Then for xamarin and blazor hybrid it has native UI control, highlikely the app is not webview but will auto add a webview when the component is Html razor pages but when the developer uses native UI it will include a native component?

In such case, the app is a mixed between native component with 1 or more webview?

But I have a requirement to get cookies from a component webview. The component load a page and user sign in to the site. It then get the cookies.

The app interact with the site using the stored cookies and display content.

Android allows app to get cookies from its webview component as long as the component is loaded by an app. Somewhere in between.

For Blazor which render as wasm and run in as one or more webview component on an app, can the webview and the app communicate to pass cookies or header?

Thank you

Wether you choose BlazorMobile or Mobile Blazor Bindings with the Webview rendering mode, you will have potentially cookies issues in your app, specially on iOS (Apple) and maybe other vendors, as security rules are being more and more strict by time, and for good reason.

Except having a "sandbox" app that would in fact connect to a PWA app remotely, so not a real app locally (and so may be refused by Apple on their store), you should never rely on some kinds of cookies for a mobile app, with or without web components.

You should instead rely on some authentication mecanisms that are suited for "offline" / external authentication. One, but not the only one, kind of offline authentication mecanism are JWT Tokens. Take a look on this on internet.

Basically, your user login on the mobile app (either web app or not) to a specific endpoint you made to authenticate it, where you will return a computed JWT Token, wich may contain more or less data in the JSON format. The basics info you should have in order to maintain an authentication in time is to have the access_token value, that authenticate directly without cookie your user on your server endpoints, and a refresh_token that should only be used and sent to the server if the expiration date of the access_token is already passed, or if something invalidated the access_token by one of your action. The refresh_token will be used to ask your webserver to generate a new access_token and refresh_token (don't remember exactly the behavior for the last one).

If the thing is implemented correctly on the webserver side to "catch" and interpret the access_token in the clients request in order to authenticate your user, the only thing needed on the client side basically is to put in all your HTTP Headers when you are doing request on client side, an header property authentication, with the value bearer youraccesstoken. If working on Blazor, you should only do this once in HTTP Headers parameters (except if the token expire and that you should update it).

EDIT: Typo, this is Authorization header value, not Authentication

There is plenty of docs on Stackoverflow and Microsoft documentation for JWT Token on Client / Server side. You may use the integrated components given by Microsoft, but third parties one can be fine too.

I actually use this kind of mecanism to authenticate users on one of my BlazorMobile projects, and the web server is only a ASP.NET MVC 5 app (so pretty old !) and everything work right.

The only thing that depend on you is when you retrieve the tokens to your client, you should store them by yourself securely on the device in order to read them from somewhere at next app boot ! On my app, i transfered them on the native side, then stored them in a SQLite database present on the device. But you can store it in many different way of course !

[sorainnosia]

Hi, for my case this is a requirement.

The website is owned by third party whom I have no controlled. The only way to communicate with their Http endpoint is by having a valid cookies which is retrieved upon login.

It is an old vbulletin website that do not receive oauth or any sort of API authentication

And the app simply retrieve the forum thread page in html and parse the threads title, and information etc then display it on a nice looking mobile app bypassing the need to open the third party website using browser which has scroll issues and not mobile friendly

I saw other developers are able to do it using flutter and flutter's webview component and retrieve the cookies and directly communicate with http endpoint using the cookies

I think such scenario still exist today because apparently many old website didn't provide API to retrieve their data but wanted mobile app that looks nice and mobile friendly

[jspuij]

It will work in a webview, it just won’t share cookies with a main browser, nor will allow password managers.

[Daddoon]

I have thought that you were expecting some kind of scenario where you are trying to authenticate from your web app current URI (like localhost or something like that with BlazorMobile). In such scenario, trying to authenticate would have been more problematic as the WebView would consider that you are doing some kind of cross domain request (first problem) and would not allow to store any cookie on the current session as they are not sharing the same domain actually.

However it may work on an iframe from BlazorMobile app, but as BlazorMobile do some kind of cleanup by Design at boot, and also that you may have some inconsistencties with Iframe depending platform (i remember Apple enforcing some additional "non-sharing" cookies scenario , i don't remember exactly what, it was a long time ago).

So @sorainnosia talking about your scenario:

• Loading and authenticating directly from the current WebView in BlazorMobile (meaning, the BlazorMobile WebView): No this is not sharing the same domain (or this mean you navigated outside the BlazorMobile app).
• Loading and authenticating from an Iframe in the BlazorMobile WebView: Yes, but beware of some cookie cleanup from BlazorMobile at next boot. This can be changed in the future if needed.
• Loading and authenticating from a dedicated "normal" WebView (not the BlazorMobile one): Yes of course no problem !

As you have access to native side (either MBB or BlazorMobile), you can easily program your workflow, to when you have to open your nice dedicated page, and also put some possibilities to easily go back to your interactive web app.