I'm using the webview tag in chromium and I want to capture the html requests. Unfortunately webview does not support proxies. Is there any way I can just do a normal http request to fiddler at localhost:8888 and somehow put the real destination in the URL? Maybe something like http://localhost:8888?url=google.com?
I'm not clear on which Chromium you're using, but generally I'd expect that it should adopt the OS proxy settings, and if it doesn't, that's a bug that should get filed.
Yes, you can send Web Requests directly to Fiddler using the technique you describe, but the cookies and security permissions aren't likely to work correctly.
Related
Chrome and other browsers support Windows Authentication via NTLM. From what I can tell though, the Chrome Dev Tools Network tab only ever shows the initial request and final response in the negotiation process. (See diagram below)
Image credit: https://www.zevenet.com/knowledge-base/howtos/load-balancing-of-webapps-with-iis-authentication-ntlm-and-asp-net-impersonation/
Is there a way to make in the tool it show all the detail about what's actually going on? It's very confusing to look at the initial request and not see any Authorization header yet have the server respond with a response indicating the client is now authorized.
Your best bet is WireShark capture.
My site is using HTTPS only.
I allow using BBCodes to show images. Users are placing images like "https://imagehoster.net/img.png" and the imagehoster is using a redirect so the browser loads it via HTTP "http://imagehoster.net/img.png". This makes the browser showing annoying mixed content warnings. Is there a way to prevent this?
Short: NO
Long:
the have no really web server listening to ssl.
in fact, there is only a firewall/proxy which sends a http locate to the browser.
You can't intercept that request. even if you could, where to redirect to?
they don't provide a ssl server, because it takes to much resources for encryption or it takes to much traffic, because proxy#s can't cache.
An idea to solve that problem:
detect those links, download them and store a copy on your server.
replace the link. maybe you need only to store a preview. if the click on it redirect to the original link on a new browser window.
I am writing a basic web application that uses <iframe> elements for certain features.
The entire site uses https, including the links to and from the iframe, but when I view the website using Google Chrome and right-click on the displayed frame and look at "View Frame Info" --> Connection, I see the following message:
Your connection to www.example.com is not encrypted
The connection uses TLS 1.1.
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
Confusingly, it says that the connection is not encrypted ... and then it says that it IS encrypted.
I thought that whenever you use https://, the content is encrypted. Am I wrong? Or is Google Chrome referring to something else?
I ended up posting this issue to the Chromium bug discussion board and someone there indicated that it's a bug.
I am working on a Web based application where the user interface is made using Jquery and the backend was developed using Java / Java EE.
On the user interface once I click on the submit button, the request goes and
the response comes from the back end. (This is not an AJAX call)
Is it possible to see what data went as request and how the response came back from the back end? Are there any such tools to view the request / response if it's not an AJax Call?
By the way I am using Chrome and Apple browsers.
Use the Network tab of Web Inspector (Chrome/WebKit) or Web Console (Firefox) or the Net tab (Firefox with Firebug)
Another option than using a browsers native network inspector (which btw DOES work for non-Ajax requests), is to use an intercepting proxy.
Burp Proxy is particular nice. It allows you to see, hold and if needed modify both the request and the response between the browser and the server. You do need to setup your browser to use a proxy. It has a somewhat steeper learning curve than the browser's native network inspectors, but once you get the hang of it it's quite an invaluable tool.
I need to call a webservice with Safari on Mac. Since the methods are in POST I can't paste the url in the address bar of Safari (like with GET methods).
So, I'm looking for a plug-in or similar that allows me to send the request and then receive the response inside the browser. The response is JSON so with the JSON plug in I can see all the response with his formatting.
Solutions ? Thanks !
Safari is my browser of choice, so I can empathize with you for wanting a native plugin. Fortunately, while there aren't any extensions available, there are quite a few native OSX clients for HTTP/REST end-point testing. I have been using CocoaRestClient, which includes auto-formatting and syntax highlighting for JSON, as you requested. It's open source, lightweight, and is at least actively supported by its developers:
http://mmattozzi.github.io/cocoa-rest-client
Another great tool is Postman, an application inside Google Chrome.
I don't know why you care whether the client is in Safari or not. A restful POST should be able to be executed from any sort of client. You might want to look at RESTClient extension for Firefox http://restclient.net/
Also just Google 'REST client' you should see plenty of other tools available to generate POST's against your service. If you are really would about Safari-specific responses, most good REST tools, should allow you to set the User-Agent header so as to make the request look like it is coming from Safari.