I'm using Charles Proxy's handy Map Local tool to develop CSS documents. This way I can immediately see my edits without having to redeploy the whole thing which in the wonderful world of enterprise-level webapps saves a considerable amount of time.
I just discovered that Map Local doesn't work with the https protocol. I have no problems with http, everything works as expected.
I'm using Windows 7, and the problem is present with every browser.
What could be misconfigured?
Ensure that the host you're trying to map is enabled under (added to) Proxy > Proxy Settings > SSL > Locations.
Old post, #OpaCitiZen's answer is correct, however, in version v3.11.4 & v4, it's
Proxy > SSL Proxying Settings > Add (URL) and obviously make sure the checkbox for "Enable SSL Proxying" is selected
Related
I'm a front-end developer working on an application where the login/ response put a Session-Cookie on the client. The later request will be authorized since the user "logged in".
Starting from Chrome 80
All cookies without a SameSite attribute will be treated as if they had SameSite=Lax specified. In other words, they will be restricted to first-party only (server and client on the same domain).
If you need third-party cookies (server and client on different domains), then they must be marked with SameSite=None.
Restricted to first-party by default
Set-Cookie: cname=cvalue; SameSite=Lax
Allowed in third-party contexts
Set-Cookie: cname=cvalue; SameSite=None; Secure
For my application, I want the default behavior. My client and server running on the same domain in production. But in development I'm working from localhost (different domain).
Up until now, chrome had special flag under chrome://flags - SameSite by default cookies. I could Enable this flag on my development machine and the login passed. And in production, I didn't need this flag because I wanted the default behavior.
Starting from Chrome 91
The SameSite by default cookies flag was removed. This means that from this version I can't login into my app, without deploying it to production.
Does anybody knows how can I get the Session-Cookie while working from localhost. But still keeping the security of SameSite=Lax. If possible with client only changes, but if needed also with server changes.
Chrome DevTools - SameSite error message
Chrome 80 Flags menu - These flags removed in Chrome 91
Update
I tried to solve this by making the server use SameSite=None (development only).
This causes a different error: Connection isn't secure. This is because when using SameSite=None you are required to add the suffix Secure and of curse use HTTPS connection.
Secure connection has its own problems like having to pay for a Certificate in development.
Workaround: Downgrade Chrome
This is not a solution! just a temporary workaround for anybody like me how got his work halted due to this update.
Uninstall Chrome
Go to "Add or remove programs" and uninstall Chrome. Notice that user data like cookies and saved browser passwords may be lost.
Download Chrome v90 from slimjet.com, or from any other site. Then install Chrome.
Prevent auto-update Chrome, according to this StackOverflow solution: open C:\Program Files (x86)\Google\Update
rename the file GoogleUpdate.exe to GoogleUpdate2.exe.
This will cause Chrome to not find the update package.
Update Flags - Open Chrome and type: chrome://flags
Search #same-site-by-default-cookies and Disable the flag
I have found a way to fix it and share it with everyone :-)
Description appears in the issues section:
Specify SameSite=None and Secure if the cookie should be sent in
cross-site requests. This enables third-party use.
In the Developer Tools section, go to the Application tab, and on the left side to Cookies:
The cookie that you want to share with other domains, mark the Secure
check and in Samesite put None. Update the site tab locally and you
will be able to use the cookies that allow you to send through the
domain of origin
I hope this brightens your day
As of Chrome v107 (Nov 2022)
I had a similar issue, spent a few hours digging, and what I found is that the only solution for Chrome is to make your front-end connection secure, ie https (using a proxy for instance): Link
An alternative solution is to use Firefox and set: about:config > network.cookie.sameSite.noneRequiresSecure=false. This allows SameSite=None; Secure=false
In our case, we are able to also run our server locally on a different port and point our client app to that localhost address for development purposes.
For example, I have the client app running on localhost:1234 and sending requests to a local copy of the server running on localhost:5678. This ensures that cookies are set successfully since the client and server are now "SameSite".
Admittedly, this is perhaps more of a workaround than a solution, but I hope it helps in the short term.
If you want to perform "unsafe" CORS requests (which means performing a POST/PUT/DELETE request) you will need to modify the tomcat conf/context.xml file, to set sameSiteCookies to "none" instead of "lax".
...
<!-- default samesite cookies configuration, for CORS set sameSiteCookies to "none" and configure bundle for HTTPS -->
<CookieProcessor sameSiteCookies="none" />
...
You can set the SameSite attribute manually to "None" + tick "Secure" inside the devtools for development.
That way you would not have to modify your production environment (keep the cookies as SameSite=Lax).
I can't intercept requests made by Chrome version 73.0.3683.86 to my localhost site.
Local host site is running on IIS on http://127.0.0.3:80
Burp proxy lister is default one on 127.0.0.1:8080
Interception rules are default one as well
In my LAN settings, "Bypass proxy server for local addresses" is not enabled
When Interception is turned ON and I reload page in Chrome browser, no request is "caught" by Burp, my local site loads and only the external requests are intercepted, such as loading external scripts from CDN.
Also under "Proxy" > "HTTP History" there is only request to external sites, and all requests to http://127.0.0.3:80 are not recorded.
When I reload same page by Internet Explorer 11, initial GET request is intercepted by Burp, as expected. Also "Proxy" > "HTTP History" shows all the requests to local site http://127.0.0.3:80
What is the problem with the Chrome? Thanks!
Found the solution late yesterday. I am using the Chrome extension ProxySwitchy, but it doesn't matter if you use that or the system proxy configuration. The solution works the same way.
You can solve this problem by adding an entry in /etc/hosts file like below
127.0.0.1 localhost
127.0.0.1 somehostname
Now burp will intercept request from somehostname
Which version of Chrome are you using?
Have you tried using the FoxyProxy Chrome extension?
As a workaround, you could modify the hosts file on your machine.
I experienced the same issue when I upgraded from Opera 58.0 to 60.0. I think that this is Chrome related, because I've also experienced it in all other Chrome browsers. Opera 58 utilizes Chrome 71.0.3578.98. Opera 60 utilizes version Chrome 73.0.3683.103. Something was definitely updated in Chrome between these versions to cause this problem to happen.
You have to subtract the implicit bypass rules defined in Chrome (https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Implicit-bypass-rules)
Requests to certain hosts will not be sent through a proxy, and will
instead be sent directly.
We call these the implicit bypass rules. The implicit bypass rules
match URLs whose host portion is either a localhost name or a
link-local IP literal. Essentially it matches:
localhost
*.localhost [::1]
127.0.0.1/8
169.254/16
[FE80::]/10
https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Bypass-rule_Subtract-implicit-rules
Whereas regular bypass rules instruct the browser about URLs that
should not use the proxy, Subtract Implicit Rules has the opposite
effect and tells the browser to instead use the proxy.
In order to be able to proxy through the loopback interface, you have to add the entry
<-loopback>
in the list of hosts for which you don't want to a proxy. It is a bit confusing, indeed.
Make sure you haven't enabled socks proxy option, it happened with me too and i found the solution when i disabled the socks proxy option, just make sure it's disabled!
Example:
It helped me
I turned on this settings
We are looking for a way to have Chrome bypass the HSTS requirements for our dev environment.
We are working on a project for https://foo.com.
Within our organizations internal dns we have DNS entries for foo.com.dev which points to our internal dev server which has historically allowed us to reach our dev server via https://foo.com.dev. Secure web requests to this site have always been met with a security warning that we have been able to bypass but in a recent build of Chrome it seems that the ability to bypass the warning has been removed. We can continue to use this method in IE but would like to be able to test Chrome as well.
Additionally, developers have been able to use there own machine names as suffixes. For example a https://foo.com.workstation10
Any suggestions would be very welcome because the prospect of reconfiguring our entire dev environment is not a pleasant one.
To be clear - access to these sites are entirely limited to internal users by both firewall setup and dns configuration.
You can try one of the following options:
Send the Strict-Transport-Security header only for foo.com, and do not specify includeSubDomains.
Make self-signed certificates for foo.com.dev on server and import in on your local device's chrome.
If your target domain is restricted only for internal purpose, you can bypass it just typing badidea in the chrome window. Further details are available here
For more details about HSTS refer HSTS RFC
I am hosting my page inside the sdcard of arduino, I have implemented web speech api feature in that, however when I test my site using 127.0.0.1/project-X , everything works perfect, but when I use 192.168.1.4(which is same machine) or 192.168.1.10 (which is other laptop having WAMP) Chrome does not allow the microphone? I have also tried to start Chrome using different flags found on Google but none of them worked. What to do? I just want Chrome to allow using microphone from local ip also!
Chrome now allows Microphone access over secured Http only. You can very easily create your own signed SSL certificate and use that to host your page via Https.In tomcat server.xml you just have to un-comment the ssl connector and point to the location of your certificate.
I'm creating an API using node js and express. As we are moving towards production, I decided to encrypt the api using ssl, (simply adding the require 'https' option and creating the requires key and cert files using openssl).
I want to continue working on the API using postman (chrome plugin), so to enable me to do this, I visited the API using Chrome, saved the cert for the API to disk and then imported that cert file (cer format) to the "personal" certificate store in Chrome. So far, so simple.
I was then able to start using the API over ssl as expected. Great.
Now, where it is starting to get a bit odd is that if I want to then remove that certificate from my personal certificate store in chrome, I was expecting to be able to just open up the settings - > htttps - > manage certificates and then to be able to remove the certificate, however the certificate is not visible in the list of certs. It's clearly been imported and is working, it's just not showing in the list. The machine in question is running win 10, so I also checked the certificate management console for the machine and I searched for the cert and cannot find it anywhere.
I think that this should be really simple, so where is that cert that I imported (and which is clearly imported and working) so that I can remove it?
Thanks!
So, I finally found the solution to this. From the command line start "certmgr" and from there I can see the installed certificate and remove it. Not sure why it doesn't show up when viewed from within Chrome?!