I have a REST API developed in IBM App Connect Enterprise v11 which is deployed on an integration server on CP4I on OpenShift, I have set this integration server (in server.conf.yaml) to use a security profile for authentication and authorization:
forceServerHTTPSecurityProfile: "{LDAP}:LDAP_Authentication"
Whenever I send a wrong username/password the broker returns this HTML response:
<html>
<head>
<META http-equiv="Content-Type" content="text/html;charset=UTF-8">
<title>401 Unauthorized</title>
</head>
<body>
<h1>{LDAP}:LDAP_Authentication</h1>
<h1>401 Unauthorized</h1> This server could not verify that you are authorized to access the document requested.<br>
</body>
</html>
Is there any way to catch this exception and override it with my own exception handler?
My current error handler catches any technical exception thrown by the nodes and maps its BIP codes to a custom defined error code and description and returns them as a JSON response, it does the same behavior with back-end business errors.
The problem with this specific error is that there isn't any thrown exceptions on the message flow level, so the error handler implemented in the REST API isn't aware of this exception at all and not able it to catch it.
I had a long explanation for why we didn't allow you to do this. Then I remembered we added support for it.
Simply tick the "Treat security exceptions as normal exceptions" in the "Security" tab of the HTTP Input Node properties for SecurityExceptions to flow down the Failure terminal.
Warning: Although we added the tick box, we had fierce discussions whether we should, it could be regarded as a Bad Idea. By allowing this you're allowing unauthorised users access to your flow, you better be very, very sure that your failure flow can't possibly divulge information to the user. Nor should it spend too much time and I/O or you'll be opening yourself up for DoS attacks.
IIB/ACE error handlers can catch and modify application and technical errors. But I don't know of any way to trap authentication errors before they are sent to the client.
You could implement a proxy API that catches the HTTP 401 from this API and returns an HTTP 401 with a JSON response. If you're using API Connect or some other API manager that would be a good place to do it. Otherwise, implement a separate API in ACE.
Related
I have implemented a proxy extending jetty's ProxyServlet.Transparent.
However upon testing I noticed there is a difference on error messages the user sees when the server returns an error.
For example, when connecting directly to one of our application server with an invalid user credential, the server should return something more specific with instructions on the auth as we have set it this way. When connecting to the proxy server the error is in its most generic form like Authentication failed: Unauthorized
I suspect at some stage jetty checks on the server response and set the proxy response with minimal information so I am looking into the Transparent class code and its parent classes to find which method I can override to intercept the original server response and forward the information in the proxy response, assuming my understanding on these two responses are correct.
Thanks for the help.
I have run into a fairly annoying problem with Quarkus, that I cannot figure out how to solve.
I am using quarkus 2.4.1.Final. I am using the quarkus-resteasy-reactive-jackson module to create a REST service.
But when I send the service a post body with a bad format the client simply gets an empty HTTP 400 response back, and nothing is printed in the log on the server side. In this particular case I forgot to add the offset to an OffsetDateTime, so adding "+01:00" makes the service return correctly. Using micrometer metrics, I can see that the endpoint is being hit correctly both when the request is correct and when it isn't.
Hiding an exception from the developer is very close to heresy for me, as I would like to be able to see what the server fails with. I understand that we don't want the stack trace on the client side, but in this case the exception is missing from the server log.
Can anyone help me to convince Quarkus to not swallow my exceptions?
enter image description here
I used the Regular Expression Extractor for the tokens, but the 403 forbidden error keeps displaying.-check the screenshoot
Seems some missing configuration issue.
Can you please make sure:
You have HTTP Cookie Manager added to your Test Plan
If your application is protected with external authentication system like Basic HTTP Authentication, NTLM or Kerberos you need to handle it properly using HTTP Authorization Manager
Can you try :
Adding HTTP Header Manager and authorization with Basic encoded
one screenshot of the failed response headers doesn't tell the full story, you need to show us:
Successful request URL, body (if any) and headers (you can get it from browser developer tools)
Failing request from JMeter URL, body (if any) and headers from the View Results Tree listener
As per HTTP Status Code 403 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 you can successfully execute the same scenario using browser and cannot using JMeter - most probably it's due to missing or improperly implemented correlation, try recording the same steps one more time and compare generated scripts, all values which are different needs to be properly worked around
For DELETE APIs, if we hit the API with invalid data, the API responds with proper error message. If we use the same HTTP connection object to hit another API, the request fails.
This issue is not seen for Create or Update APIs. Also if the Delete request is sent with valid data, then using the same HTTP connection object for next request works fine.
Please note that this behavior has implications for connection pooling in client applications, and we were just wondering if its known issue and if there is any available workaround.
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.