I have an app running on heroku and noticed today, that a particular request leads to a 400 response on Firefox but it works on Chrome. I also found out that if I remove an unnecessary cookie that requests succeeds again.
While investigating I also found an issue with chrome, where it wasn't able to fetch the CSS file, while loading the website:
However, opening that link in a new tab, I managed to load the CSS without any problems. Also removing that one extra cookie managed to sort it out.
All these 400 responses have one thing in common, they are served by the server "Cowboy"
The application I'm running is asp.net core, so it should return "Kestrel" as the server instead, but it seems that the request doesn't even get to the heroku router, because I can't even find them in the logs of the dyno.
I've tried to search online for an explanation and it seems that in case I'd be running against some limits, this is the response I should be expecting, but this is just a staging application and it works in chrome but doesn't work in firefox, so it's hard for me to imagine which limits I could be running against.
Update:
We've removed those unnecessary cookies, and now chrome loading the CSS seems to work fine, but Firefox is still getting a 400 Bad Request from the Cowboy server. Any ideas? I've only found Why do I get a "400 Bad Request" response when I have large cookies?
- which doesn't seem to apply to me, the cookies are less than 4k and all browsers should have the same cookies, there is nothing on the server to differentiate between browsers.
Related
I have two cloud services up and running.
frontend (URL: https://frontend-abc-ez.a.run.app/)
backend (URL: http://backend-abc-ez.a.run.app/)
Frontend is calling the backend through a nuxt.js server middleware proxy to dodge the CORS problematics.
The call is coming through - I can see that in the backend log files. However the response is not really coming back through because of CORS. I see this error in the console:
Mixed Content: The page at 'https://frontend-abc-ez.a.run.app/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://backend-abc-ez.a.run.app/login'. This request has been blocked; the content must be served over HTTPS.
What I find weird is that I configured the backend url with https but it is enforced as http - at least that is what the error is telling me. Also I see a /login path segment in the unsecure URL. Why is that? I never explicitly defined that endpoint. Is it the security layer proxy of the run service itself?
Anyway - I need to get through this properly and am having a hard time to understand the source of the problem.
For some reason as I rechecked the applications today in the morning everything went fine. I have really no idea why it is working now. I did not change a thing - I waited for the answers here before I'd continue.
Very weird. But the solution so far seems to be waiting. Maybe Cloud Run had some troubles.
When making multiple simultaneous network requests to the same resource, Safari, seems to return a cached version of the response. This only seems to happen when using Axios. When using fetch, I get a fresh version of the response.
Disabling network caching from the network tab seems to fix the issue. No matter what headers I put into the request, I can’t get it to bypass the cache.
Chrome and Firefox don't seem to have the same issue.
Here is a small fiddle to demonstrate.
https://jsfiddle.net/67pbntcj/4/
I have a PWA site which is working fine on Firefox, Chrome and Edge on Windows, and all of those on Android, Edge (EdgeA).
The problem
This much I know from looking at my Azure server logs:
(1) The login POST is hits a Core 2.2 controller which does the authentication and returns 302 along with a standard Core 2.2 cookie set including the authentication token for the user.
(2) The EdgeAndroid browser receives that, and immediately GETs the location specified.... except this GET doesn't include the cookies from (1), so the Core 2.2 system responds with a 302 back to the login page.
It's a redirect loop.
-> EdgeA is eating my cookies!
I can run this perfectly on the above browsers, and the logs show Edge/Windows for example has the (1)(2) sequence exactly as you'd expect, with the cookie credentials in the second request.
The only thing different is Edge Android. I stripped out all the caching from my service worker for that browser and it's still broken - I think I may need to just not run the service worker for it at all.
... and my questions are:
Does anyone have a PWA which actually works in EdgeA?
Does anyone have any idea what I may have missed? Note it's just this one browser which is broken, hence it may be them not me.
In case it is them not me, is there a place I have not yet googled where I can report defects in this possibly minor-interest browser?
This sounds similar, although that's cross-domain, and my 302 is not cross domain.
I think this was caused by the Edge Android Browser interpreting the display:standalone directive and consequently opening a "stand alone" window, which does not carry over the cookies from the original browser.
The server logs show that the EdgeA client "drops the cookies" when handling a "login successful" 302 response from the standard Core 2.2 login stuff.
My work around is to serve a specific manifest.json to the EdgeA browser, so that it reads display:browser.
At the same time I fixed this MS released a new version of EdgeA, so I can't be 100% sure if my change fixed this or if they actually listened to my whining.
I have a Rails app running in a Docker container. I use Devise for authenticating and Rack::Cors for CORS.
On my machine, everything is okay. Once deployed, I can GET the login page correctly, but when I fill in the login form and submit it, Chrome replies with a blank page and a 422 (Unprocessable Entity) status code. The Rails logs reads:
Can't verify CSRF token authenticity.
Completed 422 Unprocessable Entity in 2ms (ActiveRecord: 0.0ms)
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
Interestingly enough, on Firefox, everything runs smoothly.
I've tried everything I could find about Rails, CORS, CSRF, but I wasn't able to find a solution.
I don't really know what kind of information can be relevant here, so feel free to ask for details in the comments, I'll edit the question.
So, I had a similar problem; only I didn't have Devise or Docker. It was a simple form. Your question is missing a lot of contextual information like logs, so I can't tell if you have the same problem, but here's how I fixed mine.
I was getting InvalidAuthenticityToken errors for simple form submissions. Puzzling since it worked fine on Firefox, but would randomly fail on Chrome sometimes, and it always failed on Chrome on Android.
Diagnostics
I took a look at the log and found the following:
Started POST "/invitations" for 172.69.39.15 at 2019-09-26 22:34:26 +0000
Processing by InvitationsController#create as HTML
Parameters: {"authenticity_token"=>"F4ToAfkdPSnJsYewqvxXpsze3XitKHbiGnuEOR+628SdAY5jGRiG15GEuCSSoaVeVdO7eugAnsjKwmZPUpIepg==", "invitation"=>{"name"=>"[FILTERED]", "business"=>"[FILTERED]", "email"=>"[FILTERED]"}, "commit"=>"Apply for invite"}
HTTP Origin header (https://www.example.com) didn't match request.base_url (http://www.example.com)
Completed 422 Unprocessable Entity in 4ms (ActiveRecord: 0.0ms | Allocations: 226)
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
The line that stands out is:
HTTP Origin header (https://www.example.com) didn't match request.base_url (http://www.example.com)
https://www.example.com indeed does not match http://www.example.com, the former has SSL. I was routing my app through Cloudflare, so I had SSL, but my app was expecting a request.base_url without SSL.
Solution
You need to force your app to use SSL. This is what I did to fix this; your exact steps may depend on your architecture. Because I was using Cloudflare, I had to perform these steps in this exact order otherwise, my app could have been knocked offline:
First: I configured SSL on my server. In this case, I was using Heroku, which can use Let's Encrypt to provision SSL automatically.
Second: I configured my app to force SSL by adding the following to production.rb
config.force_ssl = true
Third: Since I no longer needed an HTTP connection between my server and Cloudflare, I switched it to from Flexible to Full.
For what it's worth, I looked back at my code to find how I solved the issue.
I wasn't able to find a clean solution, so I worked around it by disabling the origin check :
# config/initializers/csrf_workaround.rb
Rails.application.config.action_controller.forgery_protection_origin_check = false
Of course, this introduces security vulnerabilities so be sure to post your own answer if you have a cleaner way to get this to work and/or have a real explanation for the question above.
I have same problem when I change from http to https on my gitlab config. As you can see the log below.
Processing by Ldap::OmniauthCallbacksController#ldapmain as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"user1", "password"=>"[FILTERED]"}
Can't verify CSRF token authenticity.
Completed 422 Unprocessable Entity in 2ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 308)
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"[FILTERED]", "username"=>"user1", "password"=>"[FILTERED]"}
Redirected to http://172.20.1.12/users/sign_in
User cannot login with LDAPs account. I found that this problem only in chrome (I try to use firefox and firefox work like charm). After update chrome to new version this problem was gone. So may be the solution is update chrome to the lastest version. I also try lots of solutions that I found on stackoverflow but that not work.
I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.