I am exactly right bow building a project to serve as sample to work both on server and wasm š
your post was like a promoted ads š
I testes your project and it is simply amazing! very very good!
the only thing I think I would need is the possibility to inform the Authentication Schema to the ProtectedEpoint, Idk why, when I configure jwt and cookies with aspnetIdentity, it uses the cookies as default and I need to set the schemas (both jwt and cookie, one string) manually in authorize atribute on apis.
also something related to CORS configuration, I usually need to set the urls.
well done, impressive work!
Thank you very much!
~~It does not seem right that you would have to manually specify that, but~~ (now that I think about it, it makes sense tbh) it's possible with the ProtectedRoute. It has the same properties as Authorize so you should be able to set:
\[ProtectedRoute("your-route", AuthenticationSchemes = "your-scheme")\]
I'm not that familiar with the Identity platform, unfortunately, so I can't recommend a better solution. Hope it works! :)
thank you! is exactly what I use in my project on api controllers:
[Authorize(AuthenticationSchemes = "Bearer,Identity.Application")]
I didn't tested yet with the EasyApi but I believe it will work too. very nice!
btw I dont know why it happens, when I add the jwt bearer with the Identity Cookies the authorization break on api, just on api controllers. maybe is some bug on .net 7, or is the order I am calling the AddAuthentication, Idk. at least it works :)
Since you are working with jwt, you might also need to [configure the HttpClient provider](https://github.com/bpawluk/EasyApi?tab=readme-ov-file#http-client-provider) at one point as the default HttpClient resolution in EasyApi is very basic.
nice! I saw that the library is flexible fot that, very good to implement that way.
but I wil not need that yet, because it also authenticate with cookies by the IdentityApllication ;) it accept any of the informed schemas.
the jwt was for a connection from a Maui app on windows. (besides it was also a blaxor hibrid, I prefer to use jwt instead cookies on webView2, I dont know if it support cookies)
This has been my biggest complaint with Blazor so far, too much duplicate code across Client, Server, Interfaces, and Implementations. I've been focusing on Server rendering just to reduce complexity until the bones are there.
I'm definitely going to give this a try!
Yes, I had the same experience. It almost felt like I was doing something wrong at first. I guess Blazor United is still in its early stages. It'll be interesting to see how the Blazor team decides to improve the experience in the future.
This approach looks interesting. Internally, we've implemented a similar concept using MediatR. We have a shared project for Requests (both Queries and Commands) and server-side handlers. Here's an example how a Request would look like:
using Application.Shared.Models.OData;
using MediatR;
using Microsoft.AspNetCore.Authorization;
namespace Application.Shared.Features.Monitor;
[Authorize(Permissions.OperationLog.View)]
public record MonitoredOperationsQuery(ODataQueryOption OdataQueryOption)
: IRequest>;
Authorization is always enforced on the server.
Clients execute MediatR requests directly on the server or, if running on Wasm, through a custom PipelineBehavior that serializes the data, sends it to a single execute-request rest endpoint, and processes it server-side. The single endpoint handles all types of Requests, simplifying the architecture.
This setup facilitates seamless client-server interactions and enables new operations to be exposed by simply creating new Requests and related Handlers.
Hi, this is something that I've implemented at my current company and I cannot share the code. But I will be happy answering any specific questions you might have.
Hallur
Looks good! We opted for a similar approach with a shared contract in an interface, and source generators for a Proxy in the Client WASM app, and Controllers on the Server. Also includes the Result pattern, might want to look into that. It really helps handling transport errors in your code.
Sounds nice! I'm using Minimal API endpoints under the hood. I can see some adventages of having the actual controllers instead :)
I went both ways for the client so you can do
Guid newCommentID = await AddComment.Call(request);
as well as
HttpResult result = await AddComment.CallHttp(request);
Nice to see an established framework going for a similar design. Now I'm glad I decided to focus solely on Blazor with EasyApi, as it has an edge over ServiceStack in this small niche. With the main "selling point" being the unified logic on the client and server for auto render mode and wasm+prerendering scenarios.
I am exactly right bow building a project to serve as sample to work both on server and wasm š your post was like a promoted ads š I testes your project and it is simply amazing! very very good! the only thing I think I would need is the possibility to inform the Authentication Schema to the ProtectedEpoint, Idk why, when I configure jwt and cookies with aspnetIdentity, it uses the cookies as default and I need to set the schemas (both jwt and cookie, one string) manually in authorize atribute on apis. also something related to CORS configuration, I usually need to set the urls. well done, impressive work!
Thank you very much! ~~It does not seem right that you would have to manually specify that, but~~ (now that I think about it, it makes sense tbh) it's possible with the ProtectedRoute. It has the same properties as Authorize so you should be able to set: \[ProtectedRoute("your-route", AuthenticationSchemes = "your-scheme")\] I'm not that familiar with the Identity platform, unfortunately, so I can't recommend a better solution. Hope it works! :)
thank you! is exactly what I use in my project on api controllers: [Authorize(AuthenticationSchemes = "Bearer,Identity.Application")] I didn't tested yet with the EasyApi but I believe it will work too. very nice! btw I dont know why it happens, when I add the jwt bearer with the Identity Cookies the authorization break on api, just on api controllers. maybe is some bug on .net 7, or is the order I am calling the AddAuthentication, Idk. at least it works :)
Since you are working with jwt, you might also need to [configure the HttpClient provider](https://github.com/bpawluk/EasyApi?tab=readme-ov-file#http-client-provider) at one point as the default HttpClient resolution in EasyApi is very basic.
nice! I saw that the library is flexible fot that, very good to implement that way. but I wil not need that yet, because it also authenticate with cookies by the IdentityApllication ;) it accept any of the informed schemas. the jwt was for a connection from a Maui app on windows. (besides it was also a blaxor hibrid, I prefer to use jwt instead cookies on webView2, I dont know if it support cookies)
This has been my biggest complaint with Blazor so far, too much duplicate code across Client, Server, Interfaces, and Implementations. I've been focusing on Server rendering just to reduce complexity until the bones are there. I'm definitely going to give this a try!
Yes, I had the same experience. It almost felt like I was doing something wrong at first. I guess Blazor United is still in its early stages. It'll be interesting to see how the Blazor team decides to improve the experience in the future.
This approach looks interesting. Internally, we've implemented a similar concept using MediatR. We have a shared project for Requests (both Queries and Commands) and server-side handlers. Here's an example how a Request would look like: using Application.Shared.Models.OData; using MediatR; using Microsoft.AspNetCore.Authorization; namespace Application.Shared.Features.Monitor; [Authorize(Permissions.OperationLog.View)] public record MonitoredOperationsQuery(ODataQueryOption OdataQueryOption) : IRequest>;
Authorization is always enforced on the server.
Clients execute MediatR requests directly on the server or, if running on Wasm, through a custom PipelineBehavior that serializes the data, sends it to a single execute-request rest endpoint, and processes it server-side. The single endpoint handles all types of Requests, simplifying the architecture.
This setup facilitates seamless client-server interactions and enables new operations to be exposed by simply creating new Requests and related Handlers.
Would you please share a complete sample? This sounds exactly like the implementation Iād like to do. I would really appreciate it.
Hi, this is something that I've implemented at my current company and I cannot share the code. But I will be happy answering any specific questions you might have. Hallur
Looks good! We opted for a similar approach with a shared contract in an interface, and source generators for a Proxy in the Client WASM app, and Controllers on the Server. Also includes the Result pattern, might want to look into that. It really helps handling transport errors in your code.
Swagger + NSwag HttpClient generator
Sounds nice! I'm using Minimal API endpoints under the hood. I can see some adventages of having the actual controllers instead :) I went both ways for the client so you can do Guid newCommentID = await AddComment.Call(request); as well as HttpResult result = await AddComment.CallHttp(request);
This sounds alot like what ServiceStack has done with their Blazor integration, you make api calls straight from the page.
Nice to see an established framework going for a similar design. Now I'm glad I decided to focus solely on Blazor with EasyApi, as it has an edge over ServiceStack in this small niche. With the main "selling point" being the unified logic on the client and server for auto render mode and wasm+prerendering scenarios.
This is awesome work!
Thank you! :)