I have an ASP.NET MVC application running on domain a.com and this application is sending an IFrame request to b.com which is a Web API. When I debug this in the local machine (when the application and the API are running on localhost), this IFrame call works fine. But then, when these are deployed to the server, the application and API are on different domains and the IFrame call does not work anymore.
I have identified that the cookies are not sent along with the cross-origin IFrame request. So, I set the cookie properties to SameSite=None and Secure=True. Still, the cookies are not being sent with the request. How can I debug this further?
I am using google chrome version 87.0.4280.141.
See the cookies here:
See the request headers here:
Related
I'm trying to set up Cookie Authentication in Blazor WebAssembly, running in Chrome.
WebApp runs on https://localhost:44342
WebApi runs on https://localhost:44377
After a post request (with PostAsJsonAsync) to https://localhost:44377/user/loginuser with valid credentials, the WebApi sends back a response header with Set-Cookie: .AspNetCore.Cookies=...
That cookie seems to be rejected by the browser, because
I don't see it in F12 -> Application -> Cookies
Subsequent requests don't have the cookie attached
I researched the problem on the net extensively. I found loads of hints and explanations. Including configuring CORS, using the IP instead of localhost, setting cookie properties like SameSite, HttpOnly, Expiration and Domain or using chrome internals for further investigation.
None of that helped. Set-Cookie is still ignored by the browser.
Does anyone have a good idea on how I could proceed? Thanks
I had probably the same problem.
Chrome browser is denying the cookie ‘couse the domain is not using SSL and the cookie policy uses samesite:none.
I solved using a certificate in IIS (using HTTPS instead of HTTP). I had this problem only in production. For the development environment, when you create the project, visual studio asks if you want register a development certificate. Check yes.
I have two tomcat instances that I've been authenticated to from my browser and one is called from a different domain. Usually after configuring properly cors on this tomcat instance, the request will forward the JSESSION ID and be successful. But Chrome browser (v86.0.4240.80) is not forwarding anymore the JESSION ID and the request is unauthorized.
What could be the issue?
Here is the reason: https://www.chromestatus.com/feature/5088147346030592
You need to set SameSite=None to notify Chrome that JSESSIONID can be forward from another domain. (https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/tomcat/util/http/SameSiteCookies.html)
I tried to deploy a little node.js app that uses an API REST service from a third party. This API provides me some json served over a URL with HTTP
Now when I deployed the app on Heroku it wil not fetch the data from the API.
This error i got in my inspector
Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure resource ''. This request has been blocked; the content must be served over HTTPS.
It forces me to use HTTPS but I don't own that API, does this mean I cannot use it simply because it's not served over HTTPS or is there a workaround so I can still deploy the application and acces the API over HTTP?
We have a web portal and I need to add HSTS header in the response.
Ours is an on-premise solution, so we use a self-signed certificate. I have added the hsts header in the response & I need to check whether it really works.
I understand that for HSTS to work, there shouldn't be any certificate issues & first we need to access https://somesite.com then in the next pass http request will be automatically redirected to https at client side itself.
So, I installed our self-signed certificate in the chrome browser & restarted the browser. Now my connection to our web application was secure. But HSTS doesn't seem to work. In the successive calls to http://somesite.com, still we redirect (302) to https (automatic client side redirection to https doesn't happen). One thing to note here is, there is no domain name associated with our web application, we access it with our server's ip within our comapany's LAN.
Any idea how to get HSTS working?
We're using the HTML5 Application Cache feature:
<html manifest=".appcache">
...
</html>
When returning users navigate to this application they will already have all static files cached and the application is therefore loaded without network requests.
Once the application is loaded it will make AJAX requests to load dynamic content, and the browser will check whether the Application Cache manifest is outdated and possibly download a new version of the application in the background.
Many of our users are accessing this application over insecure connections (HTTP, not HTTPS).
We're in the process of introducing HTTP Strict Transport Security (HSTS) on the servers that host the application.
Implementing HSTS means that our servers will handle requests like this:
If the request is insecure (HTTP only), then the server will respond with HTTP status 301 and a Location header that redirect to the requested URI but changing scheme to https.
Otherwise; if the request is secure (HTTPS) the server will process it as normal but decorate the response with a Strict-Transport-Security header.
So, when a new user open up our application over HTTP they will be redirected to HTTPS instead and then the application cache manifest is installed using the secure location. That's perfect.
However, a returning user (over HTTP) will NOT be redirected to the secure location (because they already have a cached version on the insecure location). The application cache manifest won't load (since it's a redirection). So returning users are stuck with the application version they had cached and they're stuck using HTTP which is no longer allowed. This is very bad.
We need to come up with a way to transition returning HTTP users to the HTTPS version. How would be best do that?
The way I see it there are two problems:
The browser cannot fetch the application manifest (because it is a redirection). It is therefore unable to upgrade the application to a new version.
We could perhaps overcome this problem by configuring our servers to allow /.appcache to be served over plain HTTP.
Even if we do that, the application will still be accessed at the HTTP location (since that what's cached by the manifest)
To workaround that, we might have to implement some kind of javascript logic that changes the scheme of document.location.href to HTTPS.
I don't like this approach, but it's the only one we've got at this point.
We settled on the following solution to this problem:
When server receive an insecure request to get the application cache manifest (/.appcache in our case), then a 404 response is returned instead of the normal HTTPS redirect (301).
Getting a 404 causes the cached manifest to be stale and the browser will therefore attempt to reload the application on the next refresh, which will cause it to fetch index.html and be redirected to the secure location.