401 UnAuthorized - This request requires HTTP authentication - Payara/Glassfish - rest

Initial Context:
We're developing Web Aplication Server and deploying it in Payara Server 4.1.2.173. The mininal stability testing are passing perfect and MVP works perfectly but in order to improve the performance testing of the system we have created different test case in JMeter (3.2) that simulates Front-End normal activity and make all the necessary requests to the server.
The problem:
When JMeter starts making request REST(JAX-RS) everything works fine but suddenly some requests (users) return the following error response:
<h1>HTTP Status 401 - Unauthorized</h1>
<hr/>
<p>
<b>type</b> Status report</p><p>
<b>message</b>Unauthorized</p><p>
<b>description</b>This request requires HTTP authentication.</p>
<hr/>
It's very strange because the error appears randomly and apparently it is not because of concurrency problems.
Any ideas what might be the issue? Thanks

After a few research I've discovered that JMeter has some difficulties to add dynamic header token to Http request when volume Thread request are increasing. In my scenario I was doing the following:
Making a HTTP Login request
Generating token session in Server
JMeter gives the token from the response and I apply post-processor to encode it to Base64 and save to JMeter system variables.
In the next HTTP request I add the token in HTTP Header configuration component as a Basic Authorization.
When the amount of Threads increase (150 approx) Server return error 401. Despite of JMeter shows as if the token are included in header, there is no sign of it in the real request. The behaviour appears randomly and with no common reason...
Solution:
We have decided to add token session as a part of CSV Data set - configuration file and JMeter is capable of manage all requests without any rare 401 error.

Related

Is Chrome failing when sending a large http header?

I have been troubleshooting an error on my web app and have concluded that Chrome is failing to handle my http request when my headers get too large.
Why are my headers large?
I am using a JWT authorization scheme that includes permissions in the JWT token. With my admin account that token is growing as I have permissions for each tenant. The JWT is currently around 5200 characters.
Why do I blame chrome?
I have tested the identical request in several environments:
Swagger: fails with TypeError: Failed to fetch
Postman Chrome Extension: fails with Could not get any response
Postman Native App: Succeeds
Python script using requests: Succeeds
curl: Succeeds
For each test I have the same headers, url, and body (none because it is a GET).
Notes
While researching this, I came across this SO Question which suggests that Chrome is limited to 250KB headers. Mine are under 6k.
If I use a smaller Authorization header, then Swagger and the Postman Chrome Extension both succeed.
Bottom line:
Can we confirm my conclusion that Chrome is having trouble with the larger header?
What can I do about that?

Understanding HTTP Session security mechanism in JHipster

I am trying to figure out how the JHipster uses HTTP session for securing application and logging the user.
So far I’ve managed to understand the flow like this:
1) on landing page home.component sends request to api/account
with session cookies (if there are ones)
if there is a valid session >> uses credentials from stored cookies and then login the user
if no >> backend server responds HTTP 401 and sends XSRF cookie in response
As I understand responsible for this is Spring Security
2) when there was no acitve session we can fill the login form and log in
that sends request to api/authentication (XSRF cookie from step 1 required)
if all ok >> responds HTTP 200 and sends new XSRF cookie
if no >> HTTP 403 and sends new XSRF cookie
3) when step 2 is successful then frontend sends credentials from login form to api/account
one more time Spring Security checks XSRF cookie value (from step 2 this time)
if all ok >> business logic for log in the user is invoked
But in all these steps we need to intercept the cookies sent by backend and send them back to be able to pass through CSRF protection. Which part of JHipster project is responsible for that? Does it use webpack/browsersync or there is some Angular code created by JHipster which I am missing?
EDIT
My problem appeared when I've made a lot of changes to generated project as I want to use custom templates/styling and the services generated by JHipster. I've linked the templates with jhipster services.
When I try to log in the user I get in spring console output like this:
Forbidden: Invalid CSRF Token 'null' was found on the request parameter '_csrf' or header 'X-XSRF-TOKEN'
From previuos request to api/authentication I get response with
Set-Cookie: XSRF-TOKEN=a129cb47-ec96-47be-aaae-69f90848c466; path=/
in browser network.
So it sets the cookie with wrong name I guess. I've change the cookie name manually in browser to: X-XSRF-TOKEN and resent the request. The new error looks like this:
Forbidden: Could not verify the provided CSRF token because your session was not found.
I don't understand the flow enough so I can't spot where is the problem. Maybe I've messed up and maybe there is some code generated by JHipster which is responsible for that. There are some classes in JHipster Angular frontend like StateStorageService. Do they take part in my problem or they are irrelevant to that issue?
I was facing the same issue while connecting a mobile app to the backend of spring boot. So basically angular has a method under the core functionalities called interceptors. Under the interceptors the response is gather and X-XSRF-TOKEN is captured and updated in Browser Cookie or in my case Ionic Local Storage as Cookie.

400 status on login request for asp.net core 2.0

I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.

IBM Weather REST API 401 Keep getting CORS issues when access

I am getting a 401 and some cross domain issues when trying to access IBM Weather REST API from either client (browser) or server.
If I generate a URL and try and access it directly from a browser (eg paste it in it works fine and the JSON weather report is returned).
When I try and run the Javascript HTTP request from either the browser or server it seems like it's only allowed to run from an ibm.com domain.
Failed to load https://twcservice.au-syd.mybluemix.net/api/weather/v1/geocode/-33.00/151.00/forecast/daily/7day.json?units=m&language=en-US: The 'Access-Control-Allow-Origin' header contains multiple values 'https://*.ibm.com, https://*.ibmcloud.com', but only one is allowed. Origin 'http://localhost:3000' is therefore not allowed access.
I am using the free service on Bluemix. Is this restricted to only run via a Bluemix server? or are there some options I can pass when I create the service on Bluemix
Note, when I make the request I am using the credentials supplied via the Bluemix console. Again, this works via the browser URL bar, but not via code.
Update/More info: if I hit past the URL above into the browser (with creds) it works as above, then if hit it via the web app in the same session it works.
Hmmm. So the IBM server is sending the following response header:
Access-Control-Allow-Origin: https://*.ibm.com, https://*.ibmcloud.com
That's an invalid response from IBM. Unfortunately, I think your only option is to complain to IBM, and convince them to
Return a valid Access-Control-Allow-Origin response header (with only one value)
Allow people outside of IBM to access it
Without that, I fear you're out of luck.

Apache Camel HTTPS4 Basic Authentication

Does Camel-Http4 supports Basic Authentication?
Followed this and other posts
Camel http4 download file using Basic authentication over Https
I am using camel 2.17.3 version. using camel-http4 component. The route sends a https4 multipart request to a REST endpoint . The REST service is behind the siteminder. Have truststore/ketstore/cert all setup and it works fine, just sending basic auth is causing trouble.
Using postman i was able to call REST services with basic auth. However, all the calls from camel route fails and get HTTP error 403.
I tried below options to get it working:
Added basic auth to the HttpConfiguration - got HTTP error 401
Added "Authorization" header to the route, as mentioned in the above link - got HTTP error 403
and Added method,user,pass to HTTP_Query - 403 also clear text password is visible in the siteminder logs, this is not good, so dropped trying this option.
please help resolve this issue with some working example and explain the cause.
Is camel dropping http headers?
also i now thinking should I consider using other available components netty/jetty/cxf?? But I prefer getting HTTPs4 working :)
thanks
To help others with an working example, here is how I got it...
1) Check the site-minder policy and also ensure the user have correct permissions for the services.
2) Passing user/password as query parameter isn't safe (at least it wasn't in my case) Clear text password was exposed in site-minder.
3) setting header (Authorization)
apache-camel-basic-http-auth