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
Related
On the latest version of Chrome (Version 90.0.4430.85 on MacOS), I found that third-party cookies are disabled even though in my browser settings I checked "Allow all Cookies". I also tried adding the site to "Sites that can always use cookies" and checked "Including third-party cookies on this site", but it still doesn't seem to work. I'm accessing a course on LTI that requires third-party cookies. (The course is quite old so that might be an issue)
I'm getting this error:
Chrome Settings:
The reason I know this is because my other laptop has an earlier version of Chrome(around 80) and the cookies are working(the course loads), but it no longer works when I update my Chrome to the latest version.
When I tried in Safari, I'm able to allow third-party cookies by disabling "Prevent cross-website tracking", but I cannot find such settings in Chrome.
Any ideas on what I might try to be able to use third-party cookies on the latest version of Chrome? Also, why is it the case that this site functions in an earlier version of Chrome but not the latest? Thanks in advance.
Your browser settings for 3rd-party cookies look OK as far as testing by allowing all.
The issue may be with the LTI tool/app provider who is providing their product through Canvas and other LMS's - for example, if the LTI tool/app provider hasn't set their cookies with SameSite=None - sounds like you're suspecting that as far as course/app being older.
I think you can test this by temporarily disabling the same site requirement here: chrome://flags/#same-site-by-default-cookies
There are a few other decent testing tips from Chromium here.
If that's the issue and you still need to provide access quickly for a bunch of users, but can't wait for the LTI tool/app to be updated, you can usually update the LTI app/tool settings in Canvas to open it in a separate tab/window instead of as an iframe - e.g. these settings in Canvas.
Hope it works out!
I am developing a website which requires camera and microphone for communication.
The site uses Twilio communication for audio/video calls.
Twilio device setup is failing and is giving an error as:
Twilio.Exception: twilio.js 1.3+ SDKs require WebRTC/ORTC browser support. For more information, see https://www.twilio.com/docs/api/client/twilio-js. If you have any questions about this announcement, please contact Twilio Support at .
To which I tried to debug and found that for my website in Google settings, microphone, camera and location settings are set to Block and is Disabled.
I have tried,
Resetting the Chrome browser
Upgrading to latest version of Chrome
Re-installing the Browser
But to no success.
This is how the chrome settings looks like:
Note: This seems to happening on 2 of my laptops, although on some machines it is working properly and the settings to these items is Allow in those machines. I have a customer demo and will have to use my laptop for it.
Any help is highly appreciated!
The getUserMedia API which allows access to the camera and microphone requires a secure context, i.e. https. See this blog post for background information. Recent versions of Chrome do not make getUserMedia available on http anymore.
Switch to https which should work out of the box on Heroku.
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.
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 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