I couldn't find this explicitly mentioned in the docs, so, just to confirm, is it necessary for the apis my chrome-extension calls to use HTTPS?
Related
Google chrome has just announced that V3 extensions is the disallowing of remotely hosted code. What does this means ? are they disallowing iframe? I am unable to find any details on this?
As wOxxOm noted, it means all of your code must be in the packaged you upload to the Chrome Web Store, you cannot include code from remote servers.
From the Overview of Manifest V3 docs on developer.chrome.com:
A key security improvement in MV3 is that extensions can't load remote code like JavaScript or Wasm files. This lets us more reliably and efficiently review the safe behavior of extensions when they're submitted to the Chrome Web Store. Specifically, all logic must be included in the extension's package.
I'm running my aspnet core application locally on http://localhost:5002 and for some reasons I don't want to use https. It uses OpenIdConnect middleware for authentication and it produces temporary cookie as shown below:
As a result Chrome blocks these cookies because of missing secure flag. From the other hand this request is HTTP (insecure) and it's impossible to mark the cookies secure. The only way I see is to avoid using HTTP and switch to HTTPS which is not a good option for me for local development. Can I still use HTTP + OpenIdConnect middleware + Crome and what is a workaround?
Perhaps this could shed some light- LINK.
From the article
Chrome is changing the default behavior for how cookies will be sent in first and third party contexts.
Cookies that do not specify a SameSite attribute will be treated as if they specified SameSite=Lax, i.e. they will be restricted to first-party or same-site contexts by default.
Cookies that are intended for third-party or cross-site contexts must specify SameSite=None and Secure.
Note: this also means cross-site or third-party cookies are restricted to secure / HTTPS connections only.
Since, I am guessing, your auth server is server from another domain its a third-party cookie, so it falls under the new Chrome (>= v80) policies.
The workaround here would be either a downgrade in your Chrome version or use a browser without these restrictions.
Cannot work with firebase projects locally (I guess after Chrome auto-update). I guess it's not firebase related but Google services in general.
I get CORS error despite the fact I don't use it. CORS extension is disabled.
Error: https://securetoken.googleapis.com/v1/token?key=AIzaSyB2rVH5oURUwciXasOeGlTNW7Lye6naCn0: Response to preflight request doesn't pass access control check: The 'Access-Control-Allow-Origin' header has a value 'https://localhost:3000' that is not equal to the supplied origin. Origin 'http://localhost:3000' is therefore not allowed access.
I have tested Safari and it works, so the issue is Chrome related
I'm not an expert on this topic, but as far as I understand Chrome restricted http stuff even more.
I couldn't use https://localhost:3000 as there was no https server
I run webpack server for my js code and I've found solution to set HTTPS=true environment variable and it will enable the https option in webpack dev server.
Chrome doesn't respect such SSL certificate, but if you click Advanced -> Proceed then everything works and I don't get CORS issue any longer.
It may be a better option to generate some SSL certificate that Chrome respects so that you don't have to click Advanced -> Proceed every time, but I'm good with this for now as I can continue working on my projects.
So I chose to use Cloudflare's shared SSL certificate with CDN, now the website I sign up for has this certificate shown in the browser:
The "issued to" domain is not my domain, this caused a problem:
The https post API of my program thinks my website does not have a valid certificate
However, when I open up my site with Chrome browser, the secured icon shows up:
It seems that the browser thinks the Cloudflare shared certificate is OK,
while the "issued to" domain is clearly not my domain
So the question is:
Why does the browser trust the shared SSL certificate with "issued to" not matching my domain, while the WebRequest from a C# program does not trust?
Turns out there is a "Subject Alternate Names" field in the certificate details, which allows browsers to trust certificate with non "issued to" domain, big thanks to #SLaks.
The reason why it didn't work on my C# api access is that Unity does not support ECDH(Elliptic-curve Diffie–Hellman) for HTTPS, and Cloudflare only supports ECDH.
So, the HTTPS api to my server through Cloudflare is working for Chrome, but not working for Unity. I searched around and found it does not work for some versions of Monodevelop lineup and Xiamarin as well.
Bug
I'm using Fiddler2 on Windows to inspect and analyze HTTPS traffic. To make it less cumbersome, I've installed and trusted the Fiddler2 Root certificate. The Fiddler root certificate makes the browsing experience seamless; all the HTTPS sites are still "secured" (ie: the url is still https, and you still see a certificate lock).
But this becomes problematic when I forget to turn off Fiddler, and find myself browsing sites that I want to remain secured, only to find Fiddler still logging my traffic/content.
Is there a Chrome extension that I can install/use that would visible show when the HTTPS connection is secured by a certificate signed by a specific root?
Unfortunately, it doesn't look like such information is available in the chrome.webRequest API, which you would need to get it in a Chrome Extension.
There was previously a request to Provide information about the TLS connections to extensions via the webRequest API, but it was decided not to be implemented.