I've come across something that's puzzled me for the past 3 hours regarding Facebook's login procedure.
I visited http://m.facebook.com (with UA Spoofer installed and set to Nokia Lumia User-Agent) and proceeded to log-in whilst monitoring the headers. I purposely entered the wrong password for an account I have.
When pressing log-in it sends a POST request to this URL: https://m.facebook.com/login.php?refsrc=http%3A%2F%2Fwww.facebook.com%2F&refid=8 the status code returns a 200 response code.
Then instantly afterwards it does a GET request to this URL: http://m.facebook.com/login.php?refsrc=http%3A%2F%2Fwww.facebook.com%2F&refid=8&e=1348022&email=frankthebutcher%40hotmail.com&signup_layout=layout%7Cbottom_clean%7C%7Cwider_form%7C%7Cprmnt_btn%7Cspecial%7C%7Cst%7Ccreate%7C%7Cheader_button%7C%7Chdbtn_color%7Cgreen%7C%7CFeb1&li=jFMuUdDWbmFhq8b-zAjEOHnE&_rdr
Which is the URL that says the password was incorrect.
But, where is that redirect coming from? There is nothing in the response headers from the first POST request, and JavaScript isn't enabled.
Try it on Chrome. Would love to know how it's doing that so I can adjust the mobile app I'm developing accordingly.
Solved: In my mobile app I was sending the POST request to the right URL, but the URL string I used was encoded which was causing the problem.
The first POST request is sending back a Location header which tells the browser to step-ahead from this request and proceed with the next. The second request is just the browser then using that new Location supplied and moving forward.
here's what you see from the first POST response:
However, from what I can see it's a 302 (redirection: found) response, not a 200 OK. Something tells me that you're judging the response headers on the final request, not the intermediate redirect/handoff.
Related
Wen m trying to fire an api through the fiddler, its showing 404. On the other hand, the site is loading properly.
Your sites loads successfully, cause your 2nd request shows a 200 for localhost (and I bet this is a GET request). After the site is loaded, it seems to contain some javascript code that tries to connect to some login site (with POST to aaweb.authorassists.com) and that fails.
I want to represent a signin in a url(i.e. eclass.aueb.gr) to get the source code of the next page(the portfolio of the user).
What i have now, is the code from documentation...
var response = await "https://eclass.aueb.gr/index.php".PostUrlEncodedAsync(new
{
uname = "name",
pass = "pass"
});
Currently the response is the code of the url itself.
The page is most likely following the PRG pattern (as it should, per best practices), so the fact that the response you are getting is the original page just means you didn't code the redirect part. Do you need to? Not if all you need to do is log in. Are you successfully logged in? Hard to say for certain. response.StatusCode might be "Unauthorized" (401) if it failed (you could test it against invalid credentials), but since you're scraping a site designed for browsers and not automation (like an API), you might have to pick through that big string of HTML you got back and look for error messages. There again, see what happens in a browser when you try to log in with invalid credentials. And remember - Chrome DevTools are your friend, particularly the Network tab in this case.
I am writing a code to get through authentication to a API based web site. I have the API key that the site needs during the login process. When I call the login method with the API key, it is supposed to redirect to a predefined URL whose parameter will then contain the request token.
e.g on firing the URL in the browser,
https://kite.trade/connect/login?api_key=hcwmefsivttbchla
I am redirected to
https://impacted-purposes.000webhostapp.com/?status=success&request_token=nb0vrfota9ott1r02q153pk3422joruf
(The request token will change in every run)
Notice the request token in the URL on the redirected URL. That's what I need to get from the code.
So, I use a the code that is referred here GetFinalRedirect:
Getting the Redirected URL from the Original URL
ie. I call:
GetFinalRedirect("https://kite.trade/connect/login?api_key=hcwmefsivttbchla")
However, I don't get the final redirect. I understand there could be a Javascript redirect, but checking the response, doesn't suggest so.
Any help pls to get the final URL so that I can parse the request token from it.
Well, I can't test this since i don't have an account. And I hope thats not your real-api-key...
But the function you're using is just sending a HEAD request to server. A HEAD request has no response. With the HEAD request you will only get redirects that are included in the HTTP headers. If the redirect is done with HTML-META tags or with javascript you have to send a GET (or POST) request...
If that fails too set a breakpoint inside the function and look at the received http-headers and the response text...
I have a web application (which I have no control over) I need to send HTTP post programatically to. Currently I've using HttpWebRequest like
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://someserver.com/blah/blah.aspx");
However the application was returning a "Unknown Server Error (not the IIS error, a custom application error page)" when posting to data. Using Fiddler to compare my Post vs IE post I can see the only difference is in the POST line of the request:
In Internet Explorer Fiddler (RAW view) shows traffic
POST /blah/blah.aspx HTTP/1.1
In my C# program fiddler (RAW view) records traffic as
POST https://someserver.com/blah/blah.aspx HTTP/1.1
This is only difference from both both requests.
From what I've researched so far it seems there is no way to make HttpWebRequest.Create post the relative URL.Note: I see many posts on "how to use relative URLs" but these suggestions do not work, as the actual post is still done using an absolute URL (when you sniff the HTTP traffic)
What is simplest way to accomplish this post with relative URL?
(Traffic is NOT going through a proxy)
Update: For the time being I'm using IE automation to do scheduled perf test, instead of method above. I might look at another scripting language as I did want to test without any browser.
No, you can't do POST without server in a Url.
One possible reason your program fails is if it does not use correct proxy and as result can't resolve server name.
Note: Fiddler shows path and host separately in the view you are talking about.
Configure you program to use Fiddler as proxy (127.0.0.1:8888) and compare requests that you are making with browser's ones. Don't forget to switch Fiddler to "show all proceses".
Here is article on configuring Fiddler for different type of environment including C# code: Fiddler: Configuring clients
objRequest = (HttpWebRequest)WebRequest.Create(url);
objRequest.Proxy= new WebProxy("127.0.0.1", 8888);
I have a Silverlight (v3) application that uses WebRequest to make an HTTP POST request to a webpage on the same website as the Silverlight app. This HTTP request gets back a 302 (a redirect) to another page on the same website, which HttpWebRequest is automatically supposed to follow (according to the documentation).
There's nothing particularly special about the code that makes the request (it uses the browser's HTTP stack, it is not configured to use the alternate inbuilt Silverlight HTTP stack):
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Format("{0}?name={1}&size={2}", _UploadUrl, Uri.EscapeUriString(Name), TotalBytes));
request.Method = "POST";
All this works fine in Firefox and Chrome; Silverlight makes the POST HTTP request, receives a 302 response and automatically does a GET HTTP request of the specified redirect URL and returns that to me (I know this because I used Fiddler to watch the HTTP requests going on).
However, in Internet Explorer (v8), Silverlight does the POST HTTP request and then throws a WebException with a 404 error code!
Using Fiddler, I can see that Silverlight/Internet Explorer was successfully returned the 302 status code for the request, and I assume that the 404 status code (and associated WebException) that I get in Silverlight is because as far as I know HTTP requests that are done via the browser stack can only return 200 or 404 due to limitations. The real question is why does Internet Explorer not follow through the redirect like the other browsers?
Thanks in advance for any help!
EDIT: I would prefer not to use the Silverlight client HTTP stack because to my knowledge requests issued by it do not include cookies that are a part of the browser's session, critically including the ASP.NET authentication cookie that I need to be attached to the HTTP requests being made by the Silverlight control.
EDIT 2: I have discovered that Internet Explorer only exhibits this behaviour when you do a POST request. A GET request redirects successfully. This seems like pretty bad behaviour considering how many websites now do things in the Post-Redirect-Get style.
IE is closer to the specification, in that in responding to a 302 for a POST the user agent should send a POST (though it should not do so without user confirmation).
On the other hand, FF and Chrome are deliberately wrong, in copying ways in which user agents were frequently wrong some considerable time ago (the problem started in the early days of HTTP).
For this reason, 307 was introduced in HTTP/1.1 to be clearer that the same HTTP method should be used (i.e. in this case, it should be a POST) while 303 has always meant that one should use GET.
Therefore, instead of doing Response.Redirect which results in a 302 - that different user agents will handle in different ways, send a 303. The following code does so (and includes a valid entity body just to be within the letter of the spec). There is an overload so you can call it with either a Uri or a string:
private void SeeOther(Uri uri)
{
if(!uri.IsAbsoluteUri)
uri = new Uri(Request.Url, uri);
Response.StatusCode = 303;
Response.AddHeader("Location", uri.AbsoluteUri);
Response.ContentType = "text/uri-list";
Response.Write(uri.AbsoluteUri);
Context.ApplicationInstance.CompleteRequest();
}
private void SeeOther(string relUri)
{
SeeOther(new Uri(Request.Url, relUri));
}
I believe this was a feature change in Internet Explorer 7, where by they changed the expected 200 response to a 302 telling IE to be redirected. There is no smooth solution to this problem that I know off. A similar question was posed a while back here.
Change in behavior with Internet Explorer 7 and later in regard to CONNECT requests