Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
nebula1442307dwe are in 2020 man. auth is equal to restricting access and that is pure racism! you should not do auth xD
SortOfTested24536307dNow you're starting to understand my, "Steve Sanderson ruins everything," mentality.
This is primarily a complaint with the JWT middleware. The runtime doesn't handle any security itself. I will say the other platforms mentioned can make it simpler because they're only concerned with simple, single track auth stories.
AspNet auth uses the same base abstractions for every type of auth (identity + claims). It's not just jwt. Apps can also simultaneously have numerous types of auth (OAuth, forms, saml, ws-trust/fed, ntlm, Kerberos, etc). It will automatically analyze requests and determine which to use. All middleware is baked into this paradigm, and every permutation of those auth types.
There haven't really been any significant changes between the core 2.0 and 3.0 in the auth registration story, or even .Net 3.5 -> present. The endpoint story changed, but that's about it. Thankfully those are separate pipelines.
This all exists so any auth mechanism can use the same ClaimsPrincipal and Policy abstractions for security. It's necessary so that every security implementation supported on a given application becomes a discrete path of execution and coexists with the other auth methods any application can potentially support.
The auth story has been essentially the same since Asp.net under 3.5 (2007):
- register the modules you want
- set their configuration
- bind the message transport mechanism
- register the identity stores
- register any claim enrichers/transformers as needed
- define your policies
- apply annotations to endpoints
If you understand that set of pipelines, auth is trivial, but it does take some work to grok. The biggest thing I'll levy against MS in regards to .Net is for a number of years they outsourced the docs to the "community," so the content is by and large questionable. Core has made it a little better, but it still has a long way to go to get back to the 2005ish levels of quality.
no-oxygen249307dSignalR you say? Enjoy your neverending reconnecting / disconnecting nightmare if the client is ever behind a slow ass or unstable connection.
And what about net scalers and the likes? Oh, no, don't get me started with those.
Also, would you like to ask the back end to send some notification to any interested party? Good luck not hitting that kind of request right at the time your connection is "reconnecting". Enjoy your notifications queue management.
Moreover, have fun getting it to work with DI...
And that's about all I have to say about it. It's pretty good, when it's not pretty goddamn awful.
@SortOfTested if you dont mind im going to reference your comment in a medium article. I get that .Net has all teh right abstractions to make our lives easier for the longterm solution and i can appreciate that but also, im building prototypes most of the time and like to conrtol how simple or complex a process is based on what the applications needs are at the time. When I have stakeholders, I prefer having something to show first before having it perfected. Complexities around everyday application needs like this make prototyping very difficult. For big solutions though yeah absolutely i think .NET is astounding. Its clean, so so clean as long as one doesnt overdue their abstractions to the point that it becomes obnoxious but that can be the same with functional languages. Everything can be done wrong.
@no-oxygen your scaring me now man. I was gonna try signalR. I can find another solution utilizing a 3rd party approach.
Im actually enjoying .Nets built in dependency injection so far though. It can be rather picky at times but its alot cleaner then how were doing DI with php right now
no-oxygen249306d@dUcKtYpEd ahaha sorry dude. You Just gave me a reason to rant over SignalR and I couldn't resist It 😆
Anyway, I experienced all of the above by developing a WPF client that had to interact with a .NET api server. Your case might differ, but I'm warning you so that you could check It out yourself with a very open and ready mind.