> > 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 <https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/october/cutting-edge-policy-based-authorization-in-asp-net-core> 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 <httpRuntime maxRequestLength="xxxxxxxxxx"/>. Why is it so hard?
