Re: Core configuration woes

[Greg Keogh]

>
> If I understand the issue correctly you would do this via some custom
> middleware. I usually see authorization being done using the claims based
> policy stuff nowadays.
>

What is this "claims based policy stuff"? Who knew it was even supposed to
be used that way in ASP.NET Core? Looking backwards, I found this article

in one of my old magazines, but it's a bit skimpy. What does the
[Authorize] attribute actually do? Where in the pipeline are you supposed
to set an IIdentity? The questions go on forever.

I went down the "claims" rabbit hole and had it working. I invented a claim
called "ApiHeaderNeeded" and implemented and registered the claim and
handlers. In the handler I didn't have some references that would have made
things easier, but worst of all I couldn't find any way of setting a
suitable response in case of failure. There was some
obscure context.Success(...) method (that I would never have found without
some lucky sample), otherwise it dropped through and you got the most
cryptic claims failure error going back to the caller. I could throw an
Exception and my middleware error handler caugh it okay and sent a helpful
response, but that's cheating and going back to the old fashioned clumsy
way (I think).

So after hours of experiments I finished up writing this claims code which
I would never have discovered except by accident, and there was no guidance
on what useful things you could do in the handler.

I have subsequently found some MSFT documentation on these matters, but
there are dozens of long articles to read, full of jargon, and they often
seem to be attempting to do the same thing in different ways. Most of the
articles don't have any context, that is, they don't explain the *big
picture* about what's going on or what code should be used to solve what
problem. Otherwise, trying to extract practically useful tips from search
result developer articles on Web Api authorization and security is a path
to insanity.

I have another metaphor about parts of the .NET Framework ... I'm given a
toolbox containing a thousand tools and I'm told I can build
everything, but I don't know which tool to choose to let me build anything.

*Greg K*

P.S. Another live example: This morning we had a null crash coming back
from a web service call. It turns out that the JSON POST body was too large
and it was arriving on the server-side as null. There was no warning on the
client-side that the POST had failed. It took me about an hour of searching
and testing of different useless suggestions before I found the answer
was . Why is it so hard?

Re: Core configuration woes

[Tom Rutter]

If I understand the issue correctly you would do this via some custom
middleware. I usually see authorization being done using the claims based
policy stuff nowadays.

On Tue, Jul 27, 2021 at 6:31 PM Greg Keogh  wrote:

> It's not Friday, but I've got a complaint.
>
> In a fresh .NET 5 Web Api I want to implement the simplest authorization
> technique using a header like x-auth-key: xyzzy. I could do this my old
> legacy way of using an IActionFilter class OnActionExecuting to inspect the
> headers and cause an error response (that works). But I wanted to do it
> "the formal modern way" so I went looking for guidance. After about 7 hours
> of searching and experiments I have found nothing that works. I found at
> least a dozen samples that used completely different classes, interfaces
> and configuration, but some won't compile, some have no effect, some are
> too complex to bother coding, and those that do work do not have enough
> context information available to complete my logic or I don't know how to
> set return values.
>
> I read years ago that an aim of Core was to unify and
> simplify configuration to make it more extensible. Most of my time wasted
> today was fumbling around in Startup.cs with extension methods, lambas,
> fluent syntax and a hundred unfamiliar classes. Microsoft hasn't made
> config easier, they've made it harder than solving differential equations
> in a maze in the dark. I also spent an hour fumbling around configuring
> Swagger as well because it's now part of the problem.
>
> Overall, I'm getting progressively more upset and depressed about the
> complexity of some large parts of the .NET ecosystem. Things aren't getting
> easier!
>
> *Greg K*
>

Core configuration woes

[Greg Keogh]

It's not Friday, but I've got a complaint.

In a fresh .NET 5 Web Api I want to implement the simplest authorization
technique using a header like x-auth-key: xyzzy. I could do this my old
legacy way of using an IActionFilter class OnActionExecuting to inspect the
headers and cause an error response (that works). But I wanted to do it
"the formal modern way" so I went looking for guidance. After about 7 hours
of searching and experiments I have found nothing that works. I found at
least a dozen samples that used completely different classes, interfaces
and configuration, but some won't compile, some have no effect, some are
too complex to bother coding, and those that do work do not have enough
context information available to complete my logic or I don't know how to
set return values.

I read years ago that an aim of Core was to unify and
simplify configuration to make it more extensible. Most of my time wasted
today was fumbling around in Startup.cs with extension methods, lambas,
fluent syntax and a hundred unfamiliar classes. Microsoft hasn't made
config easier, they've made it harder than solving differential equations
in a maze in the dark. I also spent an hour fumbling around configuring
Swagger as well because it's now part of the problem.

Overall, I'm getting progressively more upset and depressed about the
complexity of some large parts of the .NET ecosystem. Things aren't getting
easier!

*Greg K*