I have successfully tested HTML5 Application Cache under Chromium. For instance:
CACHE MANIFEST
http://localhost/pycoh-mnt/materialRequisition/create
The above URL renders an HTML5 file. When I protect it with cookie-based authentication, Firefox 11 fails; I get an error whose description I could not find, but I think is due to an HTTP Redirect response. If I make the URL public, it correctly caches it.
In the other hand, Chromium 18 handles the caching properly in both cases. I'm afraid Firefox is not sending the cookie information when it issues the caching request.
Any idea? Thank you!
PD. I forgot to say I'm running 64 bits apps.
Check if third party cookies are disabled in FF. There is currently a bug in FF that prevents cookies from being sent in the manifest request when 3rd party cookies are disabled:
http://bugzilla.mozilla.org/show_bug.cgi?id=722683
Related
We recently started having issues with a web app used internally at our organization. Most users have been using Chrome to access the web app. The issue seems to correspond with the release of Chrome 90. The web app has been in place for a couple of years working with previous versions of Chrome without issue in this regard.
The web app uses an embedded iframe from a 3rd-party vendor. The vendor app does an HTTP GET to a URL within our web app to indicate success or failure. We then close the iframe and update our app accordingly. This has worked fine until recently. Now it seems that the HTTP GET from the vendor iframe is being 302 redirected to our login.
Example of 302 redirect
Prior to this and using MS Edge as the browser, the same HTTP GET gets a 200 response and our web app works as expected.
Example of HTTP 200 response
Since other browsers are continuing to work and there have been no significant changes to the web server, web app, or network access, we suspect something has changed with the latest version of Chrome and perhaps stricter security requirements. Why the 302 redirect? Does this have something with our SameSite cookie config? (Up to this point, we have done nothing specific with regards to SameSite).
We found that with the latest updates to Chrome, we had to set the ASP.Net Session cookie headers to include "SameSite=None; Secure".
This article provided the answer: https://web.dev/samesite-cookie-recipes/
We have an in-house (.Net) application that runs on our corporate desktops. It runs a small web server listening on for HTTP requests on a specific port on localhost. We have a separate HTTPS website that communicates with this application by setting the ImageUrl of a hidden image to the URL of the - this invokes an HTTP request to localhost, which the application picks up on and actions. For example, the site will set the URL of the image to:
http://127.0.0.1:5000/?command=dostuff
This was to work around any kind of "mixed content" messages from the site, as images seemed to be exempt from mixed-content rules. A bit of a hack but it worked well.
I'd seen that Chrome was making moves towards completely blocking mixed content on pages, and sure enough Chrome 87 (currently on the beta channel) now shows these warnings in the Console:
Mixed Content: The page at 'https://oursite.company.com/' was loaded
over HTTPS, but requested an insecure element
'http://127.0.0.1:5000/?command=dostuff'. This request was
automatically upgraded to HTTPS, For more information see
https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html
However, despite the warning saying the request is being automatically upgraded, it hasn't been - the application still gets a plain HTTP request and continues to work normally.
I can't find any clear guidance on whether this warning is a "soft fail", and whether future versions of Chrome will enforce the auto-upgrade to HTTPS (which would break things). We have plans to replace the application in the longer term, but I'd like to be ahead of anything that will suddenly stop the application from working before then.
Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
This answer will focus on your main question: Will using HTTP to localhost for images and other mixed content, as used in the scenario above, be an actual issue in the future?
The answer is yes.
The blog post you linked to says:
Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://.
That status entry says:
In developer trial (Behind a flag) (tracking bug) in:
Chrome for desktop release 86
Chrome for Android release 86
Android WebView release 86
…
Last updated on 2020-11-03
So this feature has been delayed, but it is coming.
Going through your question and all comments - and putting myself in your shoes, I would do the following:
Not messing with either the currently working .Net app/localhost server (HTTP), nor the user-facing (HTTPS) front-end.
Write a simple/cheap cloud function (GCP Cloud Function or AWS Lambda) to completely abstract away your .Net app from the front-end. Your current HTTPS app would only call the cloud function (HTTPS to HTTPS - not having to pray anymore that Google will not shut-down mixed traffic, which will happen eventually, although nobody knows when).
The cloud function would simply temporarily copy the image/data coming from the (insecure) .Net app to cloud storage and then serve it straight away through HTTPS to your client-side.
My web client application is setting HTTP POST requests via fetch API.
I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab.
I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back?
You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.
This is an expected behavior change according to:
https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1
I originally came across this via:
https://support.google.com/chrome/thread/11089651?hl=en
As of 2021 in CHROME the OPTIONS request is visible in the NETWORK tab filter OTHER requests
To see it together with XHR just CTRL+click and pick the request filters you want to see.
UPDATE (April 17) Chrome Version 90.0.4430.72 has made the options requests hidden again :(
Chrome 81 does not seem to display anything even after changing the option and restarting on my computer.
As an alternative solution, I started to use Firefox and its Network tab for development.
https://getfirefox.com
I'm Takashi from Chromium Project, and drove the Out-Of-Blink/Render CORS project.
The project intended to introduce a process isolated CORS implementation for better security and privacy, and many of new network related features rely on this new implementation. Unfortunately we temporarily disabled preflight support in DevTools as it turned out continuing to support it weakens security and privacy. Sorry for inconvenience during this period.
Good news is now Chrome 83 implements the CORS preflight DevTools support again in a security preserved way. So you can monitor the CORS preflight requests as you could do before the Out-Of-Blink/Renderer CORS.
Best,
I am having a small issue whereby Chrome (Version 60.0.3112.113, Mac OS) is returning a failed status response from a CORS preflight OPTIONS request.
The endpoint it is querying is a nodejs server which previously did not respond correctly to the preflight request. I have since fixed this.
The preflight request works in all other browsers, and works in Chrome on all other computers. I have tested using Browserling, and everything works as expected.
As such I am assuming (with 99% confidence) that this is some sort of caching issue with Chrome on my development computer. I have however been unable to resolve this, and have at this point tried deleting any/all cache options that I can find in the various Chrome options menus.
Can anyone share any insight?
I could not find a way of clearing whatever internal cache Chrome is using in this regard.
My resolution was simply to append a query string (based on the build time) to the request such that Chrome does not use this internal cache.
This is a good way of versioning resources (JS, CSS, API endpoints etc) anyway.
I have an existing site that works fine over http and https (SSL). The SSL certificate is valid and can be confirmed by inspecting in the browser.
I am starting to use a manifest file to enable the HTML5 application cache on my website. This is useful for making the page load faster, and eventually for offline capabilities. This is working great when using a regular http connection. The problems happens when accessing the site over https (SSL). When I do this, I can access my website's content just fine, and the URL says "https" however I see the following behavior:
Safari: It displays the lock icon, but when I click the lock icon to inspect the certificate, it says that the certificate is invalid.
Firefox: Does not display the colored address bar indicating encryption, and when inspecting the certificate, it says that there is no certificate.
Chrome and Opera: Correctly displays the secure nature of the URL, and when clicking the lock icon it displays the SSL certificate information. Yes!
I understand that using the application cache causes resources to be served locally from the browser, and as such there is no encryption happening, however customers don't necessarily know that there is an application cache happening in the background, and they are expecting to see a valid SSL certificate and indications that the connection is secure. Safari and Firefox appear to be doing this incorrectly, unless I am missing something. That is my question. Does anyone know how to get Safari and Firefox to display the SSL certificate for pages served from the application cache? Is there something special that you need to do, or is it a Safari and Firefox bug?
I believe someone has discussed this with me before. Please let me know if this helps.
Change all of your script and css references from
http:// or https:// to //.
If you haven't any then it is moot, but if you do, please let me know if that has an effect.
I believe this may be related to not being able to verify the references from a cached page.
Based on the history of vulnerabilities, I'd guess this may have been overlooked for the sake of fixing more critical issues. That said, I think this should be reported to both vendors now that some of the glaring vulnerabilities have been patched. Have you tested this with the latest releases of Firefox and Safari?
Did you serve the application manifest over SSL?