I have web application where I am uploading the large file more than 1 GB from browser to the server. Depending on network speed some time it will take more than 1 hour.
Server endpoint is secured with OAuth.
When upload request is sent from browser it has valid token with 1 hour expiry.
In case of large file upload, it gives Unauthorised error because of token expiry after 1 hour.
How can I solve this problem where token should validate only in the beginning of the request not after complete file upload?
Technology used
AngularJs - UI
SpringBoot version 2 - Backend
POST request
Content-Type: Multipart/form-data
I dont have option to increase the token expiry beyond 1 hour.
The reason is that the tomcat will receive the file firstly, then dispatch the servlet request to your controller. When the upload takes too long time and the token has already expired, the security check will return 401, and your request will never enter the controller (the security check is before your controller).
You can put a breakpoint in your controller with the MultiPartFile parameter, then try to upload a huge size file to verify what I said.
One possible solution is you resolve the servlet yourself, maybe something like:
uploadFile(HttpServletRequest rawRequest)
Then when a token already expired, you can refresh it rather than return 401 then discard the already uploaded file.
Hope this may help you, and if you have a better idea, please let us know. Thank you!
useful link: https://docs.spring.io/spring-framework/docs/5.3.x/reference/html/web.html#mvc-multipart
Related
Our team is developing a simple Angular website that sends a form data to our backend via API. This website will be published under a public IP, so the interaction will be protected with Google reCAPTCHA v3.
Recently we decided to run some stress tests in a pre-productive environment in order to see if everything is stable and works correctly. So we set up a simple JMeter tests group with 100 users and 100 loops. This way we had 10000 requests in total to our API. So, having all that configured, we ran the frontend in order to generate a reCAPTCHA token, executed the action which sends the data to the API and copied the generated token into the JMeter configuration.
The API, before passing the form data to the backend, checks if the token is valid by making a request to “https://www.google.com/recaptcha/api/siteverify”, specifying this token and the secret key generated in the reCAPTCHA admin console.
After executing the JMeter tests, we saw that a certain amount of requests bypass the validation of the token and end up in the backend, while the token has already been used.
What we tried?
Stress test of our API with 10k requests in order to try the validation of an already used reCAPTCHA token.
What we expected to happen?
All the requests to return an error code of 401, beacause the reCAPTCHA token has already been used before and those tokens are single use only (the 401 code is returned by our API if the request to "/siteverify" returns a "success:false" in the response body or a status code other than 200).
What actually resulted?
5% of the requests bypassed the validation and ended up in the backend.
JMeter results
(The 400 bad request errors are returned by the backend, after the validation of the token has already been done, meaning that the token was assumingly valid)
We chequed the logs of our API and we've been able to verify that, in fact, the "/siteverify" requests return a status code of 200 and a response body of "success:true" in those 5% of the tests.
To me, it seems like some kind of balancing problem, maybe some node didn’t have enough time to replicate the status of that token? Or maybe the problem comes from our implementation… Hopefully someone could give us a hint!
I have an app built with Spring Boot, it's using Apache Tomcat 8.5.53.
It all works fine, but sometimes my users get the following message:
HTTP Status 403 - ForbiddenType Status ReportMessage Invalid CSRF Token '1423gi43-3452-65t3-cg8d-21a75cd7gc3x' was found on the request parameter '_csrf' or header 'X-CSRF-TOKEN'
Then they refresh the page, login and it all works fine.
This doesn't always happen, and it doesn't happen for the same request. My users perform normally other operations before they see this message. However, it happens most of the time on post or patch requests.
I have seen issues on stackoverflow where token is null, but in my case it randomly expires.
I don't want to remove the token.
Has anyone experienced (and hopefully solved) this issue before?
I'm debugging a scenario in my production environment where I intermittently see unexpected HTTP 401 responses from my resource server. I'm using Spring Security OAuth2 (the "old" OAuth libraries; pre Spring Security 5.2.x and its implementation of OAuth2) to handle requests and perform Authn.
What I'm observing is the following:
A user logs in at time x (time in seconds here) and obtains an access token. That access token expires at time x + 900 (15 minute validity).
At time x + 480, the user makes a request to a protected endpoint.
The request takes a long time to complete, such that it's still being processed when the token expires. At time x + 900, the server returns a HTTP 401 response.
Questions:
Is this really how Spring Security OAuth2 works? To be more specific, does it track the token's expiration time and return a 401 if the request is still being processed when the token expires? Or on the other end of the security filter, when the response is being prepared?
Is there a way to disable this behavior, so that the token is only checked when the request is first processed?
I had a look at the source code for spring-security-oauth2 and this is not how it works. The token expiration is only checked one time, at the beginning of processing of the request.
I traced the issue I was having above to a problem in which our server resources were maxed out for a period. When resources (CPU; HTTP request worker threads) became available, the server started processing the request, but by this time the token had expired.
I have a web api which is deployed on IIS.
Api's are going through load test using load runner and almost on all alternative api call, getting 403 error response code, struggling to identify the issue, call is not going to the API, its returned back from IIS
I am doing bearer token authorization, somehow token which were incoming with each request were not valid, that is why the issue was occurring, to overcome this we have increased the lifetime of token to 1 hour and request load test team to generate the token once and send that token only with each request so that we can now see the proper execution time for each end point.
403 error indicates that access to the requested URL by the client is Forbidden for some reason. you need to provide detailed error message snapshot and what is the sub status code. and check that you assign this permission to the site folder:1) IIS_IUSRS,2)NETWORK SERVICE,3)IUSR
How oData or AJAX services should respond when the authentication cookie is expired and it's time to renew?
What should the server send to the client when
An oData or AJAX service access is forbidden (access denied)
When the session credentials are stale, and need to be renewed, perhaps by redirecting to an ADFS, OpenID, or Azure ACS IDP
Just looking in Wikipedia lets me guess that I should send some version of 403.x for the first scenario, and a 401 for the second scenario.
Please confirm if the above is correct, and what I should include in the response header and body as well.
Some examples I assume to be incorrect do the following:
Silently error out the AJAX service and return no data
Attempt to redirect the AJAX call to the IDP
Send error text to the client that is not in JSON format
its always safe to play with the HTTP Status codes instead of cooking up your own tokens or anything of that sort.
Since the fundamentals of OData is to make it possible for any client which knows how to communicate HTTP, it makes sense to play around the HTTP status code. The clients will decide what to do on a particular status code.
HTTP Status Codes are the way to go. OData specifically doesn't define anything that is already implemented at a lower level (such as security and authentication.)
401 is for Unauthenticated, 403 is for Unauthorized. For secnario 1 you only say "Access denied" but not why you're denying access. Is the user not authenticated? Then return 401. Is the user authenticated but lacking privileges? Then return 403.
For scenario 2, I would agree, return a detailed 401 status (i.e. with a valid "WWW-Authenticate" header for your authentication provider.)
The Wikipedia article I recommend starting at (you may have already found this) is: https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_status_codes
Hope this helps someone. :-)