Our website http://www.monfatec.com is using the navigator.geolocation.getCurrentPosition function to get the long and lat of the client.
But it always responds with a PERMISSION_DENIED status, this, whatever the browser and client, from both Firefox 58.0.1 and Chromium 64.0.32 on my Linux pc, as well as from Chrome 64.0.32 on my smartphone, and it is consistent and occurs on every request.
The website uses http and not https and that might be an explanation for the issue, but I'm not sure.
As of Chrome 50, the Geolocation API will only work on secure contexts such as HTTPS.
This will also be the case in update versions of most other browsers.
Related
Chrome v59+ claims to have blocked URL embedded credentials, but some users are saying they were able to get it working with newer versions such as Chrome v96:
I tested with the latest chrome v96 and it works. But you do have the point that the solution is dependent on the fact that the browser supports it and might not work on different browsers.
In my own testing, I was not able to get this working with Chrome v96, anyone know a list of current supported browsers for URL embedded credentials that would register HTTPS for Basic Auth:
http://username:password#domain
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/
I know their are answers about this subject (some are even fairly recent like this:
Chrome does not show request cookies when "Provisional Headers are shown"
Or this:
Chrome show Provisional headers are shown without cookies in request
unfortunately none of them worked for me since newer versions of chrome (in my case 76.0.3) don't have the Enable network service.
I did try to disable the site isolation AND Runs network service in-processand as I said, not with great results.
Image of possible network flags
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?