I am using an api and I noticed that when I use RestSharp and do a call from my asp.net web api project my request fails.
I turned on fiddler and for whatever reason the api I am requesting thinks I am a mobile device and thus is redirecting me to the mobile site that does not support api calls.
I then did a request in fiddler and I can access the api. I changed my user-agent to fiddler through restsharp and now my requests go through when using my web api.
I don't want to leave it fiddler though. What should I use instead?
You are in-effect creating your own user-agent, so invent your own identifier. E.g. choboAgent/1.0
Related
I am using the Postman native app on Windows 10 and am struggling with trying to capture https requests. Postman's Documentation for this is for Mac and not Windows.
In particular, I am working on a web application that creates a session cookie upon login that needs to be included in most requests in order to be authorized. When I was using the Chrome App, Postman Interceptor achieved this (see https://stackoverflow.com/a/32436131/3816779).
Here's what I've tried so far:
Turn on the Proxy in Postman with port 5555.
Configured windows to send http and https requests through Postman's proxy server (127.0.0.1:5555).
This allows http requests to be captured in Postman
But when trying to connect to https sites, I get an error
Here are my Postman settings if that helps.
Update I ended up switching back to the Chrome App, which uses the "Interceptor" instead of a "Proxy Server" to capture traffic.
Unfortunately, capture https requests with postman native app is impossible in some case according to the official doc: Capturing HTTP requests
Note: for the Postman native apps, request captures over HTTPS will not work if the website has HSTS enabled. Most websites have this check in place.
Postman's proxy now supports HTTPS traffic - https://blog.postman.com/postmans-proxy-now-fully-supports-https-endpoints/
Once you install a CA certificate that Postman generates for your installation, capturing HTTPS requests should be seamless.
Disclaimer: I work at Postman
With Google Chrome i don't know how to fix the issue. But you can use to open the web page for example IE..
EDIT:
Or MAYBE you can start Google Chrome with parameter --ignore-certificate-errors to ignore the error message.
Postman Interceptor is available for Postman native apps which supports both features:
1. Capturing requests
2. Syncing cookies
Learn more here.
Just check HTTPS in setting and will work for you
I have a ASP.NET MVC based web site which runs on http.
From the above web site I'm making a https call to a web API
Configured fiddler as a proxy and trying to monitor the traffic using Fiddler Web Debugger (ver 4.4.8.4)
I only see "tunnel to" requests to the https web api sent from the MVC web application. Why am I not able to see other https traffic including request/response headers/body?
I have enabled decrypting https setting in fiddler. I have followed this link:
http://fiddlerbook.com/Fiddler/help/faq.asp
Is there anything else I can check?
Let's step back a bit:
Is the HTTPS request to the web API being made from JavaScript on the client, or from ASP.NET code on the server?
Did the request actually succeed?
What, if anything, do you see in Fiddler's LOG tab?
I want to communicate via AJAX calls with a back-end server from a PhoneGap application.
Is there a way to associate the PhoneGap application with a domain that I own so that the requests don't all have to use CORS or JSONP?
If not, is it preferable to use CORS or JSONP for these AJAX requests from PhoneGap?
You do not need to be concerned about cross domain requests from a mobile device. They somehow don't matter. Your device can make requests to any site's JSON service just fine. If, however, you want to test locally on your PC prior to building and deploying to a device, you will need to use JSONP. I always use JSONP for that reason.
I plan to use https to build a website. After the user logs in, s/he is directed to a dashboard. The dashboard will be developed using javascript and html5. What are the thing I need to keep in mind when I make ajax calls using SOAP to a web service while using https?
The most important things:
always use the same domain name, otherwise browser will throw cross domain errors,
always use https protocol for every ajax request, so browser won't get same origin errors.
On the server side check for X-Requested-With: XMLHttpRequest HTTP header, to be sure that the request came as AJAX, not standalone GET/POST request. This is only difference.
With AJAX request browser will send the same cookies value as in the any other request, so you can surely check user session with it.
I have two apps named opentripplanner-webapp and opentripplanner-api-webapp. I had successfully deployed them on local tomcat server. Apps has url as http://localhost:8080/opentripplanner-webapp and http://localhost:8080/opentripplanner-api-webapp. When i deployed apps on appfog , they give me different domains for both apps. The problems is that my apps use ajax request and responses which does not work on cross domains. I am searching for two days to find any solution but didn't find any suitable solution. Kindly guide me.
Thankss
Here's a couple of options for you:
Use JSONP (JSON with Padding). You would have to write your api so it supports this protocol, but it shouldn't prove too difficult.
Create both opentripplanner-webapp and opentripplanner-api-webapp so they support Cross Origin Resource Sharing. This means that your webapp sends an Origin header in the request, and the server responds with an Access-Control-Allow-Origin header, and if they match, the browser accepts the request. This is however not supported by all browsers, although most modern browsers do.
Use a proxy servlet in your opentripplanner-webapp that proxy requests to your API. You can "mount" this servlet at e.g. /api in the webapp, and it will forward all requests to opentripplanner-api-webapp internally. So you would send your AJAX requests to http://webappserver/api instead of http://apiserver. For the browser, this will look like an ordinary same origin request. This will work in all browsers, but might require some more setup.