I would like to know if the following is possible:
As part of the PageLoad of an ASP.Net page request:
Use HttpWebRequest (POST) to make a request to a forms authentication
webpage of a different web application
Examine the response to see if the authentication succeeded (identifiable if an authentication cookie has been set)
If it fails, then finish the ASP.Net page request, which will display a message saying "couldn't auto-login" or some such thing
If success, then instead of completing the ASP.Net page lifecycle, use "Response.Write" to send the response from the HttpWebRequest back to the browser (thus essentially displaying the webpage from the HttpWebRequest)
If the above is possible, then, is there also a way to transfer the authentication cookie from the HttpWebResponse to the requesting browser? My gut feeling is probably not - but if this is the case, then how do proxy servers handle such things? Is that not essentially what they are doing?
Thanks for any help
You can add a CookieContainer to the HttpWebRequest. It will store any cookies received from the response and if you attach the same cookie container to the next request, it will send those cookies back up to the server.
You can access the contents of this CookieContainer object and send those back to your client using Response.Cookies.
Related
As per my understnding the difference between Response and Request is below
Request is - We request to server for like .aspx page
Response is - We get the .aspx page from server
So, I think, request is toward Server and response is what we got.
We have following terms
Request.QueryString
Request.RawUrl
Request.MapPath()
All these seems to go to server first and brings back the associated data. But the following term is contrary ?
Request.Cookies
Because the cookies creates at client side and value part is also fetched at client side using Response.Cookies
Your comments?
Query - 2 - Why it is useful to create/Access cookie using Request/Response.cookies? Because it can be created/fetched at client end in JavaScript.
Query 3 - Cookie resides at client end. Why do we send request to server ?
Query - 4 - Why do we write Response.Cookies? to go to server? Why? it creates at client end and accessed from client end. right? Why do we write Request.Cookies? Means fetching cookie information from server? Cookie is at client end. right?
"When a browser makes a request to the server, it sends the cookies for that server along with the request. In your ASP.NET applications, you can read the cookies using the HttpRequest object, which is available as the Request property of your Page class. The structure of the HttpRequest object is essentially the same as that of the HttpResponse object, so you can read cookies out of the HttpRequest object much the same way you wrote cookies into the HttpResponse object."
ASP.NET Cookies Overview
"Cookies are sent to the browser via the HttpResponse object that exposes a collection called Cookies. You can access the HttpResponse object as the Response property of your Page class"
Beginner's Guide to ASP.NET Cookies
Every time you send a Request to server, the cookies for that server are also sent.
Also, when the server sends you a Response it can include cookies for the next Request you send it to.
So Request.Cookies and Response.Cookies make perfect sense.
Both objects Request and Response "live" in the server. So Request holds the data sent by the User Agent (the Browser, like Chrome, IE, etc.). Examples of this data are, the POST and GET Variables, the User Agent, the language, IP Adress, and many more.
Response is the object that lets you send data to the User Agent (the browser), i.e. a Web Page, a stream of bytes (like a downloadable file), etc.
The cookies live in the client side, that's right, but is the browser that send this information, so this data comes in the Request object.
You receive the cookies via Request.Cookies, but you receive the cookies in the Server. If you are coding in C#, the code is in the Server point of view, so receive means, the server receives. If you want to access the cookies in the Client Side, you must use some client programming language like JavaScript.
I hope this helps.
I have a Jquery Ajax request which goes to Facebook server. (jsonP)
However , Im not satisfy with the current response and I would like to "edit" the response before it goes back to the ajax call.
In order to do it , I was thinking about building a proxy by ashx. ( it will do the request , and when the response is back - he will edit it , and it will return to the ajax call).
jQuery ajax ---> myHandler.ashx ----> Facebook +--->
|
|
jQuery ajax <---- myHandler.ashx(+edit) <-----------+
the problem is that Facebook requires its cookies , And IMHO -only facebook can access its cookies.
Is there any way for the ashx handler to be able to TRANSFER the cookie along with his request ( as if jQuery ajax would do ) ?
Technically, you may simulate a cookie-aware user agent and relay them to user.
Request 1:
Browser sends the first request to your ashx handler.
Your handler relays it to facebook server.
FB responds with a content + a set-cookie header(s) (fb-cookie=xxx on facebook.com)
Your handler edits the content and returns the set-cookie header with some kind of prefix (your-fb-cookie=xxx on yoursite.com)
Request 2:
Next time the browser sends a request to your ashx handler, you will receive the the "your-fb-cookie=xxx" (as it is defined on yoursite.com)
Your handler relays the request to FB with the cookie "fb-cookie=xxx"
...
However, be aware that facebook (or any other service) may (and should) use some kind of anti-flood detection.
It may block your server's IP adress as it receives lots of requests from it.
This can even be against FB licensing terms.
I would like to make a periodic background request from JavaScript on the client to my web application (ASP.NET, IIS 7), but I don't want the request to affect the ASP.NET session timeout.
Is there a way to do this?
You have to avoid sending cookies with your request because that's how session ids are transmitted.
If you have an xmlHTTPRequest object, you can remove your cookie header by calling xmlHTTPRequest.setRequestHeader("Cookie", "");
I am using an SMS Gateway to make my application receive SMSs. For this, the SMS Gateway sends a request to one of the pages in my application with the message as a querystring parameter. eg. http://myapplication/SMSReceiver.aspx?Message=PaulaIsHome.
Now after my page gets invoked, I need to send an OK response to the SMS Gateway so that it doesn't keep retrying to send the same message to my application again and again. I cannot figure out how to send the OK response.
I am using ASP .Net and C#.
Thanks
You are invoking an ASPX page, so I am guessing that a bunch of HTML is being returned in the response. Use a generic handler instead (this is what they are for), and then you can easily control all of the output...
context.Response.ContentType = "text/plain"
context.Response.Write("OK")
context.Response.End()
I want to post data to another server (JSP or ColdFusion).
Note: Post which means the data is required at the another server also the browser should be redirected automatically.
Is it better to use
form tag...input type hidden fields, values
...
and from javascript
form.submit();
or
HttpWebRequest myRequest =
(HttpWebRequest)WebRequest.Create("http://...");
myRequest.CookieContainer = new System.Net.CookieContainer(10000);
myRequest.Method = "POST";
myRequest.ContentType = "application/x-www-form-urlencoded";
myRequest.ContentLength = data.Length;
Stream newStream = myRequest.GetRequestStream();
newStream.Write(data, 0, data.Length);
newStream.Close();
return myRequest;
or
I should use WebClient class?
Please provide the points from Security view also.
If you want the browser to be correctly sent to the other server, then you should really do this client side - your second option will send the response from the remote server back down to the client, but any links in the HTML that are relative will appear broken, as the user will be attempting to request them from your server.
Also, making the request from the code-behind, you'll be sending the request from your server, without any of the client's cookies, headers, etc for that site (which you won't have access to).
The other issues to consider:
Client may have JavaScript disabled.
If the remote server supports SSL, then you should probably be posting to that.
Doing this client side, you'll be sending all form data to the client initially, and then sending it on to the 3rd party server.