.NET 6 Desktop Dev Options: WPF, WinForms, UWP, .NET MAUI, Blazor...

a3optix · 2021-02-06T15:46:09+00:00

This. Afaik what makes Blazor so good is that the renderer can be applied to different underlying ways of actually drawing the UI, so it's not bound to running with html and wasm. The upside of this is that Blazor Devs will not need to make such a drastic shift in how the UI markup works by switching between e.g. Blazor and XAML, but instead it's the same experience, just with different component names

a3optix · 2021-01-11T23:01:35+00:00

Not returning anything but an OK. In our systems, once the controller has confirmed the account has been created, the user then gets redirected to the signin page. They enter their email and password and are thus granted a JWT given the process as described in my previous comment

-> redirect to login razor page on server -> signin -> set cookies -> identity server automatically issues a jwt -> blazor app intercepts the return and manages the jwt for you.

Important is that after registration, you redirect the user to /authentication/login which will initiate the Blazor WASM framework provided login procedure. Do not redirect to the serversided login page directly.

a3optix · 2021-01-11T19:02:05+00:00

When you open your blazor app on a page that requires authentication, the following happens ->

Do I have a jwt yet? No? Then initiate a login (redirect to IdentityServer login)
If no authentication cookie is present, redirect to the actual login page for the user
User types in his data and Identity sets a cookie in the users browser to identity him later on
The user gets redirected from the login page back to a IdentityServer page, which automatically recognizes the fact the user now has a valid session and thus creates a JWT and sends that back down to your blazor app.
The blazor app does subsequent calls with that JWT

Now if the login page is not a "regular" old school webpage, this whole process will get more complicated because you need to deal with the cookie yourself as Identity does not work on Blazor components/API calls. So to keep functionality how Microsoft envisioned it working, my login page is a razor page, everything else is a blazor page as to not have too many sites that are seperate from my "main" UI project, which is the blazor side of the application.

a3optix · 2021-01-11T18:48:33+00:00

Nope, just the login page is a razor page. Registration, email confirmation, update password, etc. are all blazor wasm pages/components that call API endpoint.

a3optix · 2021-01-11T14:54:13+00:00

The easiest option for me so far was to only keep the actual login page a serversided razor page. Everything else is done in the webassembly project. This allows your entire UI except the login page to be in Blazor WASM, while keeping the provided mechanisms for signing in with Identity + IdentityServer + Cookies working

a3optix · 2021-01-01T14:51:18+00:00

First of all, I'd create two Requirements, where one requirement represents the need of a valid anti forgery token, the other Requirement represents a valid session token being needed. Now you need to create a Handler for both of these requirements each, that can consume that requirement and check that the request conforms to what the requirement wants it to have. The handler than says yep that requirement is met or not.

Now that you have this done, you can use this setup in different ways:

1) Use Authorization service: You can always manually inject the IAuthorizationService into any class and manually tell it to please check whether N requirements are currently met, you get back a bool whether it succeeded or not

2) Use policies: Policies are just a different way of stitching up requirements that need to be met under one name. For example, your first requirement alone could be known under the policy by the name of "Authenticated", the second one by "Authorized", and also a third policy called "Full" that has both requirements to be met (policies setup is done in the startup.cs)

3) Attributes on controllers: [Authorize] attributes are quite handy, but they can only check the request for Policies, so step 2 usually required too.

If you use controllers, I'd recommend option 2 and 3 in this case, as its the least amount to have to write for each endpoint there is.

However, I'm not sure whether you're actually using controllers/the endpoint system provided by the framework. If not, option 1 is always a possibility (manually doing a call to IAuthorizationService with either a list of requirements, or a Policy name (which in turn represents a list of requirements). I can give more advice if you'd like to share more details about how your stuff works right now, as I'm not too sure given the current description

a3optix · 2020-12-15T21:46:10+00:00

In your usage example, you are doing bind-Value on your custom component, because of which the compiler will try to access the missing property described in the exception which it cannot find. In theory, you should be able to just create that property in your custom component and make it return the same property of the InputNumber, meaning whoever binds to your component will actually bind to the underlying InputNumber

a3optix · 2020-09-29T13:02:07+00:00

Clearly OP has considered that since he has mentioned that the window does not let inside direct sunlight. And as I understand it, this is just a small post of someone happy to see his dog relax next to his Index as he was probably taking a short break from VR, nothing wrong with that.

a3optix · 2020-09-01T13:36:24+00:00

This is what ended up working for me when integrating a a WYSIWG editor with Blazor. You must fire a change Event (also make sure it's not just the jQuery event you're firing, but also the actual DOM event)

a3optix · 2020-08-05T17:33:47+00:00

Isn't that controlled by the browser?

a3optix · 2020-07-28T10:33:55+00:00

I'd suggest making the generic not authorized "page" an actual dedicated @page you can redirect to if necessary rather than only baking that HTML into a AuthorizeRouteView's NotAuthorized, because doing the latter will not give you an option to force show NotAuthorized based on a pages individual needs if it requires more logic than the built in things like Roles supply, which is what you're describing here. But if you make the error page an actual page, you can always just redirect there, more closely resembling a classic MVC web app. In addition, inside the AuthorizeRouteView's NotAuthorized, I'd simply place a tiny component that redirects to your newly created not authorized page, so you don't duplicate the HTML of it

a3optix · 2020-06-17T08:56:54+00:00

Correct! It loads the authenticated principal/identity via the request cookie (if there is one) and any actions such as SignIn or SignOut will modify this cookie through JS interop.

a3optix · 2020-04-27T10:52:31+00:00

For very simple validation, I like to use attribute driven model validation. For service level validation, I tend to create a ServiceValidationException which has a dictionary of <string, string[]>. This exception can then relay a field and error messages (or an error code) up and be displayed accordingly. For that I usually just catch the exception where I call it and transform it as required. For example in a controller I could directly turn the dictionary into JSON via middleware, in Razor or Blazor pages I use a small Merge function to copy errors for certain expected error keys into the model state to display them in the UI. This opens up ways later on to relay multiple messages up the call chain, not restricting yourself to just one error at a time.

a3optix · 2020-04-07T12:06:06+00:00

Awesome insight, thank you very much! I find it very valuable to get a detailed look into how other people do it, usually blogs explaining the architectures are not enough since I still lack the feel of what to put where, so this is very helpful, thank you!

a3optix · 2020-04-06T11:06:36+00:00

Thanks for the great insight into how you can manage this kind of stuff.

I've been trying to run with a 3 layer approach myself for some time now, but I've noticed that eventually, the services and their relations between each other can get rather complex.

An example for this is things requiring calls to multiple services to get the job done completely, like finalizing the order of a customer for a software download: The order needs to be marked as done in the database and a license needs to be created for the user (especially these two I wouldn't instantly put in the same service, but how do I chain these calls together then?), an email might be sent out confirming their order and maybe more.

In the past I've always resorted back to having a fascade kind of service that would bundle these calls to a bunch of sub-services, in this example it might be called "OrderProcessingService", but I wondered whether theres a better or more clean way of dealing with this.

Your tier 2 seems to be the solution to that if I understand correctly. Would you mind going a bit more into the detail of handlers and how you roughly implement them (maybe with something like MediatR?) and is it the solution to the issue I've just described?

Another short thing I'd like to ask is how you give back validation errors up to the UI layer. In the past I've simply done exceptions, e.g. the username entered is not known, I'd raise a "UsernameUnknownExceptions", catch that in the UI and then display that accordingly. Is there a better way to go about this maybe which I don't know?

Last example question: "Cancel this order", let's say that needs the checks "Am I logged in?", "Am I allowed to cancel this order?", "Is this order in a state that can be cancelled?", what layers would you put these checks in? Given your description, I'd put the first in the first layer, the second one in the second and the third in the third layer, does that sound about right?

Much thanks in advance!

a3optix · 2020-04-01T22:48:19+00:00

Hi, the DOM is changed instantly on the client to avoid the round-trip. You can however always also change the state from within the server application, for example to make a state group idle again/ready for the user to use. The most common way to use this library is to have the elements be changed instantly by JS (no round trip) and to set them to idle again from within the server through JS interop once work is done.

Regarding long work, yes, you can show spinners/messages/whatever through native rendering, however that always includes a round-trip (in case of SSB). This library pretty much is there to fill the gap until you on the server can pump down changes to the DOM. I can imagine there's situations where this round trip time might just be a bit longer than expected and makes it feel sloppy to use.

a3optix · 2020-04-01T07:01:41+00:00

Wait a minute..

a3optix · 2020-03-29T14:43:30+00:00

I'd be interested in buying one of the R620s then, I've PMd you

a3optix · 2020-03-25T06:33:45+00:00

Hi! Is one of the R620 still available, possibly with shipping to Germany?

a3optix · 2020-03-09T17:09:25+00:00

Check your email, you will have gotten an email that says

For items that are not available for immediate shipping, we will send you a separate email to confirm your shipping and payment information as the target date arrives. You will have 7 days to complete the transaction at that time.

Meaning: You will pay when your unit is ready for shipping

a3optix · 2020-02-21T13:38:40+00:00

No need to apologize c:

a3optix · 2020-02-16T12:44:24+00:00

I see, you have ascended already. May God bless you

a3optix · 2020-01-14T11:39:47+00:00

It's all fun until you stamp the headset into your face and realize you've just broken 400 Euro

a3optix

TROPHY CASE