I have a webapi service in/under DNN V7 (IIS/10 on Win10 Dev box).
It works fine but i have one scenario i wanted check the response i get with expected basic auth responses since i don't seem to be able to find this answer elsewhere.
Controller method is marked with these attributes (which validates using basic auth)
<HttpGet>
<DnnAuthorize(StaticRoles:="TestRole")>
Providing valid user credentials in basic auth header for a user with this role returns
200 ok. all good so far.
Not providing basic auth header at all, returns 401 not authorised, all good and expected.
however, providing basic auth header with say a wrong password or username, returns 500 internal server error.
So is a 500 error correct if the user/pass IS provided BUT wrong?
In my head i should be getting 401 not authorised as it has credentials to validate, they were just incorrect. So i wouldn't expect it to blow up with an exception, just return not authorised?
the call stack isn't very revealing
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.WebHost.HttpControllerHandler.EndProcessRequest(IAsyncResult result) +113
System.Web.Http.WebHost.HttpControllerHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IAsyncResult result) +10
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +9836613
System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +50
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +163
Does basic auth (or DotNetNuke's implementation of the of the DnnAuthorize attribute) return a 500 error intentionally for security purposes? Did i get a setting or config the api controller wrong? basically what am i missing here?
A 500 status code implies that the server messed up and expects the client to retry, as such it is never related to security, and clearly indicates a problem somewhere.
There are two possible sources of issues:
Configuration of some other middleware in your application.
Validation of username/pass is incorrect, and it is actually passing, but then failing at a later point in your code.
DNN's SDK source has a bug in it.
The reason this is a 500 is because your application isn't handling the failure that is being thrown. It is being caused by one of the two sources (or both above) but as a result your application throws the default 500. It's possible to catch this problem and throw a 401 instead, but it is likely better to tracedown the problem.
First step would be to validate that your code in the step actually isn't being executed. It's possible something there is being executed when you expect it to not be (like userId is NULL instead of the right value), and the problem is really somewhere else.
Also, given that V7 is not the latest version, and from searching around there are other SO instances of DNN having issues before V9, I would suggest validating the problem on a later version. And then if it is still an issue posting it on the relevant github issues.
Related
Should I pass the 403 on to the client so they know to work on their account permissions? Should I return a 424 since there was a problem with a dependent service, or should my response be a 5xx status code?
I've scoured the internet and have been unable to find anything useful, although I imagine this is a fairly common situation. Thanks in advance.
I am running into an issue with an API Gateway/Lambda implementation. I've written a authentication service that works across subdomains and appears to work fine in most cases. Testing locally works perfect.
When it is deployed to AWS, with the API in a Lambda with an API Gateway in front of it, the log in system works great. The user can login, which returns a 200 and then a ReturnClaims-style endpoint returns their access, and other useful account bits.
The problem arises that after a little while (like an hour or so usually) the ReturnClaims endpoint will continue to return a 200 but the response is now empty when the page is refreshed.
The HTTP-Only cookie still lives in the browser and it's not throwing any errors.
When running locally, this issue doesn't arise at all. The user can refresh for as long as the cookie has and JWT has been instructed to last (which is 30 days but I've adjusted this for testing purposes as needed).
I am hoping someone might have an idea of what might cause an endpoint on AWS to function in this manner, perhaps some life setting I am unaware of?
I appreciate any advice or suggestions. Thanks!
I am new to JMetet and I am having a lot of difficulties in understanding how it works.
I created a TC to add an object to my system using Blaze meter. Then, I imported the TC in Jmeter.
This TC fails when it should not (at least thats what I think) because whenever I use the system it works correctly:
This is the thread group if you need it to help me:
Am I doing something wrong? AM I missing something?
IMPORTANT: Should I be able to see my object added to the system if the TC passes?
As per HTTP Status Code 403 Forbidden description:
The HTTP 403 Forbidden client error status response code indicates that the server understood the request but refuses to authorize it.
This status is similar to 401, but in this case, re-authenticating will make no difference. The access is permanently forbidden and tied to the application logic, such as insufficient rights to a resource.
If your script assumes authentication most probably it fails somewhere somehow due to missing or improperly working correlation, for example this eedd968fe... bit
looks utterly suspicious, most probably you need to replace it with a some form of dynamic parameter extracted from the previous request using a suitable JMeter Post-Processor
Normally the flow looks like:
Open login page
Identify and extract all dynamic parameters and save them into JMeter Variables
Send the parameters along with credentials in the 2nd request
Check out Using Regular Expressions to Extract Tokens and Session IDs to Variables article for example challenge and solution
I want to make a Post to write some data into the database, but all needed information is stored on the server, so my Post service requires no body:
#PostMapping("foo")
public #ResponseBody
RestResponse writeFoo() {
// WRITE AND RETURN
}
If I try to make a post request to this service I receive 401 even if I pass a valid token. If I change my exposed service to a GetMapping all works as expected. It seems that I can't manage a Post request with an empty body.
I've tried adding some fake parameters as
RestResponse writeFoo(#RequestBody(required = false) String fake)
but without success.
Any idea?
The issue you explain is most commonly the cause of bad (or missing?) configuration.
Pay attention that i.e. GET method is allowed by default by your REST API, while you need to specify other method types (i.e. PUT and POST), otherwise it won't work out of the box due to CORS.
The part where GET method works while POST method doesn't is a strong hint towards missing/incorrect CORS configuration. You can fix it quickly by adding some CORS filter and setup your response headers.
The official documentation should give you a good start, if you don't know where to look for: Spring docs - enabling CORS
UPDATE:
The issue is successfully resolved, check comments section for more info.
Short story - back-end configuration for CORS/CSRF token was set up correctly in this particular case, the issue occurred due to missing header (CSRF token) on the angular/front-end part of the webapp.
How to add the unhandled exceptions accross the applications in response body in WEB API. If there is no exceptions a success message needs to be sent to the response body for all the responses....Need help on achieving this.
You need two things. For handling the exceptions, you need to set the IncludeDetailErrorPolicy in the HttpConfiguration object,
You can configure the error policy preferences as part of the configuration object (HttpConfiguration) in the IncludeErrorDetailPolicy property. This is just an enum that instructs Web API about how to deal with exceptions.
The possible values for this enum are,
Default: It’s uses the customErrors configuration settings if you are using ASP.NET as host or LocalOnly for self-host.
LocalOnly: Only includes error details for local requests
Always: Always includes error details
Never: Never includes error details
When an exception happens, Web API will check the value on this setting for including details about the exception in the response message or not. For example, if Always is enabled, Web API will serialize the exception details as part of the message that you get as response.
The success message does not make much sense as you already have the response status code. A status code equals to OK means that everything went ok. If you still want to add an additional message, use a HttpMessageHandler that checks for the response status code. If the status code is OK, add the message. However, the response body has been set already at that point so you will not able to modify it. You might able to add a message as a header.