In Fiddler when I look at Tools > Fiddler Options > Connections > Show Gate Info,
I see the upstream gateway, which is calculated from the IE settings it adopts on startup.
Is there a method to get the gateway info.
Or is there a way fiddler saves the gateway info, which I can program to read it?
The Gateway info in Fiddler's About dialog shows the upstream gateway, which is calculated from the IE settings it adopts on startup.
Fiddler registry settings are subject to change at any time, and should generally be set using only the Fiddler user-interface. In particular, the settings should not be set, or directly replied upon, by Fiddler Extensions.
HKEY_CURRENT_USER\Software\Microsoft\Fiddler2
for more update check http://fiddler.wikidot.com/registrysettings
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).
Open Chrome and navigate to google.com
In Fiddler use the "Any Process" button to select that Chrome tab
In Fiddler the "Any Process" button changes to something like "chrome: 11788"
In the Chrome tab search for something
I expect traffic to be captured by Fiddler but no sessions are displayed. If I use "Any Process", traffic is captured from all applications.
The "Use Filters" checkbox is unchecked in the Filters tab.
I uninstalled and reinstalled Fiddler.
I have the latest version installed.
What else could I do?
Modern versions of Google Chrome use separate process for making requests; so the process of the main window, detected by the 'Any Process' tool, is different.
The team is considering a fix, but it is currently not implemented, see "Target Any Process" feature no longer working with Chrome.
Possible workarounds meanwhile are:
Use other filtering functionality - e.g. capture a request from Chrome, and from the Sessions view choose right click -> Filter now -> Show only process=<process number>.
Filter everything else. In Fiddler, uncheck Tools -> Options -> Connections -> Act as system proxy on startup. Then Start Chrome with manually specified proxy settings, pointing to the port on which Fiddler is listening:
chrome --proxy-server=http://localhost:8888
This way the only captured traffic will be from this instance of Chrome.
Detailed version: Why Fiddler's Process Picker tool doesn't work with Chrome anymore
Brief version: For security and performance reasons Chrome now handles network requests through a separate network service. So when you are pointing the 'Any Process' tool of Fiddler on any Chrome window/tab, you are actually pointing to the UI (browser process) of Chrome browser.
There is one quick workaround for this:
Navigate to chrome://flags/#network-service-in-process in your Chrome browser. You would see Runs network service in-process and its value would be set to Default.
Change the value from Default to Enabled. By doing this you are telling Chrome to handle network requests from the browser process which also handles the UI.
Restart Chrome. You should now be able to capture network requests by pointing the Any Process tool on any Chrome tab.
Once you are done with your development activities do not forget to set the flag back to Default. This would give better performance.
NOTE: At the point of writing this, I am using Chrome 84.
I'm debugging a local site.
I'm getting the following message in chrome.
Your connection is not private
Attackers might be trying to steal your information from t.buyamerica.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID
This is not new, and normally I just click ADVANCED and Procced ...
but lately it just stuck in a loop and display the error message again.
This is a local site therefore the key-pair is indeed invalid, but is there a way to by-pass this issue without installing a proper https for all my local (vagrant based) servers?
NOTE:
The current by-pass for me is to use the same domain as the original site, so that the local site is www.somesite.com, and the actual site is somesite.com
I solved this issue as follow:
In
System Preference -> Network -> WiFi -> Advanced -> Proxies I saw that Secure Http Proxy (HTTPS) is checked and the value for the proxy is localhost:8888
I unchecked the Secure Http Proxy (HTTPS) and it seems to solve the issue.
NOTE: this is a specific MAC issue that apparently caused by a system upgrade (my current version is 10.10.5 (14F2511) Yosemite, MacBook Air (13-inch, Mid 2012))
I never set a proxy server or run any proxy on localhost:8888
You change your local domain something like http://yourdomain.test.
Don't forget the 'http'. And if you're using .dev, change it to .test
I've just auto-deployed a LAMP stack on Google Compute. Before when I did this successfully I had to enable HTTP and HTTPS. Now it seems like they've changed the interface totally again.
And this time I find the options to enable are greyed out.
I tried accessing my phpmyadmin at [ip address]/phpmyadmin and it timed out...so clearly http and https are not being allowed in....
How do I enable HTTP and HTTPS access?
This is what it looks like right now. Not sure where to go from here as the option is totally greyed out.
Ok, the answer is to hit the EDIT button at the top.
I do express the opinion though that this is the most un-intuitive (yet glossy) interface I've ever used.
I suffer no shame!
You can do the following:
Your instance is associated with the default network. Click on the default link.
This will bring to the default network settings where you should review all the Firewall Rules
Check if there are any firewall rules with tcp:80 or tcp:443 present for traffic. This will allow access from outside via http, https. If not, click on Add Firewall Rule and then provide access to those ports.
Alternately, you can also use gcloud to manage your firewall. Refer to gcloud firewall command example here.
Is the "Use Proxy" option on an HTTP Connection in SSIS 2012 broken when not using credentials?
I have a Web Service task in SSIS 2012 that works well normally. When I modify its HTTP Connection to use a proxy without credentials, it seems to ignore my choice and not use the proxy at all. When I specify credientials, it then uses the proxy.
To figure this out, I set it up both ways, and ran Fiddler with capture off. Fiddler with capture off will still show traffic specifically routed through it as it acts as a proxy.
Below are the screenshots with details. You should be able to reproduce this.
First, I note the port that Fiddler is set up with:
Then, I leave Fiddler running but not capturing:
Then I set up the HTTP connection to use the local Fiddler proxy explicitly:
Then I run the Web Service task, and note that nothing shows up in Fiddler.
This tells me that, in this case, SSIS isn't actually using the Web Proxy as I asked it to. Anyone know why not?
To be sure it is working otherwise, I then set up the HTTP connection to use the local Fiddler proxy explicitly, but this time with credentials.
Then I run the Web service task, and note that the request now appears in Fiddler, as expected. So what was wrong in the earlier example?
It looks like the only way is to make the user name and password blank, but leave the box checked. I was surprised when this worked. I am not sure if this is related to how my particular proxy is set up, so your results may vary.