Pretty sure I know the answer to this one, but want to make sure I'm not missing something...
Running ASP.NET 4.0 and have a request where I need to send a user to a 3rd party app but set an HTTP header value before doing so. This would be a Request header. I can set the Response Header no problem but am unable to do so with Request headers as the collection is read-only. Essentially, the process is as follows:
User clicks button to initiate transfer to 3rd party app
Page posts back and we grab user info - at this point I need to set the header
Issue a Response.Redirect and send them to the 3rd party app.
Note: I'm not stuck on a Response.Redirect; I could change the form to POST to the 3rd party app simply as a means of transferring the user, that's fine.
I believe I could setup an IIS rewrite rule to set the header (based on this article: http://learn.iis.net/page.aspx/686/setting-http-request-headers-and-iis-server-variables/) but I don't want to go that route as the header value will contain a UserID and I'd rather not expose that to the user at all - even for a brief moment. I certainly understand that even a header isn't invisible as someone could inspect the page, but I'm not concerned with that.
Any ideas would be a great help.
Thanks,
Ryan
How about:
using System.Net;
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.google.com");
req.Headers.Add(new HttpRequestHeader(), "my header content");
Related
How to Hide query String URL in Spring MVC
We are using third party URL, when we hit the URL it open a PDF, we want to hide some parameters in query string URL. In the URL there pass invoice number and Date both parameter we want to hide, when we hit URL in any ways.
If we cannot hide the using query string while using URL tag? What is the alternative for the above scenario.
URL: http://abcxyz/GetDocument?DocumentClass=INV&invno=098765546&invdt=11/01/2016
You may be able to use a POST request rather than a GET, that way the parameters do not appear in the url, but this will depend on whether the third party will support a POST request.
A GET request will always show the params in the url. If you leave out the parameters, the request probably can't be completed properly.
A user would still be able to see what was sent even if using a POST request or javascript to fetch the document. Their browser's development tools will show the requests and the parameters. This makes sense since it's their browser that is making the request and you can't stop them from checking what data they are sending out or receiving.
One way I can think of is to have your server request the page from the third party and serve that to the user's browser. That way your user will be requesting the data from your server and doesn't need to know about the third party at all, you will have control over the url that serves the pdf.
One caveat I would add is that you might want to check the third party's terms of service to see if this would violate them.
In a web application using an MVC layout, should HTTP Headers be set in the controller or the view? My thoughts:
Controller: Setting the header here seems appropriate, as this is part of taking a request, and setting necessary variables to handle it on the server side.
View: An HTTP header is really just a few lines of text above the rest of the content being served up, and that text is arguably the view.
I wouldn't gasp to see headers set in either location. What is the best practice?
The view’s responsibility is anything that is sent to the user. The format of the content doesn’t matter. The view doesn’t know how that content will be parsed – in a web browser, a console, Lynx …
An example: you want to debug your AJAX requests and send data about the inner processes to the browser. You don’t want to mangle that information into your DOM, so you use HTTP headers instead. These headers are meant to be viewed in the browser’s debugger. The view in your application just doesn’t know if you are actually looking at its output.
Basic rule: whenever you sent a single Byte to the user, use the view.
So I have a webpage, ("http://data.terapeak.com/verify/") and I don't see any & tags in the URL so I am unaware how to post data to this. I need to do this via HTTPRequest rather than browser control. I am creating a double threaded batch searching program. I have already successfully made this using a single browser control but that wont allow for multi-threading, atleast with my current knowledge due to the fact that even when creating a new frmBrw that already exists it needs for me to set the threat apartment to single. If i set it to single, I am unable to have it send the data the the excel sheet I need both threads to access. I hope this is clear... The basic question is how can I log into this form via HTTP request.
This isn't going to be easy to answer without further details however I suspect you'll need to provide the variables via a HTTP POST request.
Can you successfully login to this page in your browser? If so, run a proxy tool such as fiddler and check the HTTP headers it makes to the server. You should see the form variables being passed over. You then need to mimic this in code.
How to: Send Data Using the WebRequest Class
Hope this gets you started
Is there a way to know if the request has been redirected or forwarded in the doGet method of a Servlet?
In my application, when a user (whose session has timed out) clicks on a file download link, they're shown the login page, which is good. When they login, they are immediately sent the file they requested, without updating the page they see, which is bad. Basically, they get stuck on the login screen (a refresh is required).
What I want to do is interrupt this and simply redirect to the page with the link, when a file is requested as a result of a redirect.
Perhaps there are better ways to solve this?
The redirect happens client-side. The browser is instructed by the previous request to send a new request, so to the server it does not make a difference. The Referer header might contain some useful information, but it's not certain.
When redirecting you can append some parameter, like ?targetPage=dowloadpage and then check if the parameter exists. You may have to put this in a hidden field on the login page if you want it to be transferred through multiple pages.
If you're using container managed authentication, then I don't believe you can detect this since the server will only involve your resource once authentication has been completed successfully.
If you're managing authentication differently, please explain.
In the current HTTP spec, the URL fragment (the part of the URL including and following the #) is not sent to the server in any way. However with the increased spread of AJAX, which uses the fragment to maintain some form of state, there are a lot of situations where it would be useful for the server to have knowledge of the URL fragment at request time.
For example, if you go to http://facebook.com, then click a user name in your stream, the URL will become http://faceboook.com/#!/username - to allow FB to update your page without reloading all of its bootstrap JS and HTML. However, if you were to reload this with your browser, the server would have no way of seeing the "#/!username" part of the URL, and therefore could not pre-render the content for you. This forces your browser to make an extra request once the client Javascript has loaded and parsed the fragment.
I am wondering if there have been any efforts or proposals towards creating a standard mechanism to achieve this.
For example, there could be a standard HTTP header, which would be sent with the value of the URL fragment - any server which cared about such things could then have access to it.
It seems like this would be a very useful thing for the web-application community as a whole, so I am surprised to not have heard anything proposed. Perhaps I missed it though.
Imho, the fragment identifier really is not a good place to store the state, it has been designed for something else.
That being said, http://www.jenitennison.com/blog/node/154 has a good discussion of the whole subject.
I found this proposal by Google to make Ajax pages crawlable, but it addresses a more constrained set of use cases. Specifically, it creates a way to replace the URL fragment with a URL parameter to obtain the same HTML output from the server as would be generated by a client visiting the equivalent URL with the fragment. However, such URLs are useless for actually running the Ajax apps, since they would necessitate a page reload every time.
Webkit Bug 24175 - URL Redirect Loses Fragment refers to Handling of fragment identifiers in redirected URLs which may be of interest.
A suggestion for a future version of HTTP may be to add an (optional)
Fragment header to the request, which holds the fragment identifier.
Even simpler may be to allow an HTTP request to contain a fragment
identifier.