/?wc-ajax=update_shipping_method is giving me 403 response with the contents of "-1". Because of this, payment methods do not refresh based on the selected delivery method.
Can anybody help please?
Thanks!
I am suspecting a cache issue here, Most of the Ajax requests require nonce for the security checks and if You're using a cache plugin then it's possible the nonce value is also stored on the cache, and because of that nonce validation is failing and you're getting 403 response.
The nonce value changes every 12 or 24 hours (I am not sure about the exact time period), so validation with the old nonce value will always fail.
Try to disable your cache plugin and if you're using cdn then purge the cache then force reload the page then test the issue.
Related
After the most recent Firefox update (68.0), I am having problems with persistent session data.
When a user logs in, as the page loads, there are various expected CSP violations that send a POST request containing the violation report to the path report-uri directive contains.
Subsequent API GET requests to retrieve user data returns a 403 Forbidden, which (by design) redirects the user back to the login page. Since the user is logged in already, same API requests are sent that result in another 403, which leads to an infinite loop until after an arbitrary number of loops API requests return 200 OK.
All requests (both POST and GET) before and after the update are the same.
It seems to me that the fact that there are CSP report POST requests before the API requests changes something related to the session, which is used by the back-end to determine if the user has the correct privileges.
Could Firefox have changed something about the way it handles CSP report-uri requests or their responses change with the update?
What would be a good way to approach this problem?
Firefox has just been updated to version 68.0.1. The update seems to have fixed this problem. Release notes don't seem to be related to this in a way I can make sense, but regardless, the problem is solved.
We are experiencing an issue and appreciate any help on it please.
In our application, AJAX(using simple $.ajax with a POST ) requests are getting html content from server and it all works fine in Chrome/FF/Safari but user session is lost in IE and Edge if the size of the returned content exceeds 30kb. If the returned payload size < 30 KB it all works fine in IE as well. So basically the ajax request returns successfully but we can see that session cookie is lost in subsequent request.
Please note that same ajax handling mechanism is working fine on a number of other servers.
Attached are the details of request/response headers of working and non working
environments
Request response headers - snapshot from working environment
Headers
Request response headers - snapshot from Non working environment
Headers
Please note the difference in response headers. Kindly let us know if you need any more information on this.
Well it turned out to be be browser cookie limit. IE11+ Impose a limit of 50(increased from 20) cookies per domain and we were exceeding this limit. IE simply knocks out the older cookies if this limit is exceeded(Including the session cookie).
http://browsercookielimits.iain.guru/
https://support.microsoft.com/en-us/help/941495/internet-explorer-increases-the-per-domain-cookie-limit-from-20-to-50
I want to enable CSRF in my SailsJS and Angular 2 application but I have been having endless problems.
The Angular app is on a page that is only accessible after a user has logged in, controlled by Sails policies.
Then I http.get the CSRF token from the /csrfToken route and store it, adding it to HTTP headers when doing a POST.
I was continually getting CSRF mismatch errors and I finally realised that the /csrfToken route was returning a different value every time, both from a http.get and also when accessing the URL from the browser.
It wasn't clear that this was happening when I went through this tutorial (see 00:30) for a multi-page application where the CSRF value is submitted as a hidden field in a form, and there doesn't seem to be any mention of how to change this behaviour in the Sails documentation.
How can I configure Sails so that it will maintain a single CSRF value for a session?
UPDATE: It’s working now
I have made my update an answer as advised.
It turns out that there were different issues that were causing my problems.
My code had become so fragmented that I didn’t realise I was referencing an older function that was putting the CSRF into the header wrong.
I rolled back a bunch of client-side code and then magically the CSRF value remained consistent between Ajax calls and also worked correctly in the POST request.
So I guess there was something in my fragmented code that had caused the CSRF token to change between API calls but I don’t know what it was.
Visiting /csrfToken in the browser still produces a different result every time but it does not seem to affect the API calls.
EDIT
I discovered that the CSRF changes with each request to /csrfToken. One of my mistakes was that after I stored the CSRF value the first time I then (accidentally) requested a new /csrfToken again later, which then invalidated the stored value. Using the stored value would then result in a CSRF mismatch error as a new value had been issued.
The rest of the script is working properly but on checkout getting 403 / 404 error. I am not getting why it is happening. Do i need to pass cookies or session Id to get successful checkout or what can I do. please suggest in brief.
Even if you get "green" result and HTTP Response code 200 it doesn't guarantee that your test is doing what it is supposed to do, add View Results Tree listener and inspect response details starting from login, I think your test even doesn't perform a successful login.
So a couple of general recommendations:
Always add HTTP Cookie Manager to your Test Plan
Magento uses some form of CSRF Protection so you will need to get form_key parameter form the previous response and add it to the next request. See the following reference material for more information:
Magento CSRF attack: A Simple Explanation
How to Load Test CSRF-Protected Web Sites
I'm using Firebug's NET feature to measure the performance of our application. I'm a bit confused the way it is displaying the timeline. We have enabled Expiry header for all static files(it is 30 days from the current date). Now even if the resource is available in cache, it still makes a conditional GET (that is what I think). Ideally there shouldn't make a connection to the server, but it takes 93ms to create a connection. Please find the image that I've attached.
Can some one please help me to understand this better?
The HTTP response contains a header entry "Etag". ETag is a cache validator tag.
The HTTP Client on seeing this response will always verify with the server if the Content has been updated.
Cache Validator tag has higher preference over other Cache control tags.
If you want content to be served from cache without it being validate on the server side then only keep the Expires header and remove the ETag header.