Direct linking to a gov.uk ASP page (possibly user session related) - asp.net

I am unfamiliar with ASP but I need to link directly to a page on the http://carfueldata.direct.gov.uk/ website which I assume from the .aspx extension is built in it. My problem is that when a user first clicks on the link, the destination page immediately redirects them to the home page, presumably because there is some kind of user session required (?), I do not know. Not a good user experience for my visitors. The second time you follow the link it displays happily. The chances of my users following a link twice is slim.
Is there a standard URL parameter or something that I can append to tell the ASP platform to generate a user session and not redirect.
To see problem for yourself open this link in a new window, then close it, and repeat. First time it will redirect to home page. Second time does not: http://carfueldata.direct.gov.uk/search-new-or-used-cars.aspx?vid=30392

It looks like they are using session for this purpose. As far as I know there isn't any way to override this.
But you can do some work around for this.
Call jQuery ajax function to homepage and redirect on its complete event.
While calling the ajax function the cookie (ie session set) will be set on client's browser and after the ajax call redirect user to the page.( The page that won't allow users to visit directly)
Click to go
function LinkClick()
{
$.ajax({
type: "get",
url: "http://carfueldata.direct.gov.uk",
dataType: 'jsonp',
complete: function (msg) {
window.location.href=" http://carfueldata.direct.gov.uk/search-new-or-used-cars.aspx?vid=30392";
}
});
return false;
}

When you initially submit the request to the website, you receive a 302 status (moved (temporarily)) and a redirect to the home page. This is because there is no session ID cookie in your request. The redirect response from the server creates the session ID cookie for you and from then on, the site honours subsequent requests.
I don't know which client library you are using, but it should be possible to intercept the redirect request sent by the server, and replace the redirect URL to the homepage with your original request URL. Since the redirect response contains the session ID cookie, we can assume that the session has been created and your original request should work immediately without the redundant visit to the home page.

Related

Push into browser's history via HTTP headers

I need to make the client to navigate through a series of redirects. After the user arrives to the destination, I'd like to allow the user to go back to an intermediate page to be redirected elsewhere.
For example, take the following diagram:
Current Page -> Processing Page -> Landing Page
Status: 3XX
|
V
Alternative Page
Disclaimer: I do not have control over Landing Page but I do have control over the others.
From the Current Page, the user is sent to the Processing Page which, after checking the DB, redirects the user to the Landing Page. What I would like is, if the user presses the back button, to be sent back to the Processing Page so it can redirect the user to the Alternative Page.
The problem is that, because of the 3XX status code, the Processing Page is never injected into the browser's history so when the users goes back, they are sent to the Current Page directly.
So far, I've achieved my goal by making Processing Page to return 200 and force a redirect via JS as the first thing but it feels like a clunky solution.
Would it be possible to achieve the same outcome with a combination of HTTP headers? Another solution, since I have control over Current Page is to place the decision making algorithm there but this is a complex enough page already that I'd rather prefer to avoid this option.
Many thanks!

Asp.net - prevent parameters replication during redirection to login page

Asp.net, when it sees an unauthenticated request, typically send the request to the login page.
An example is below:
http://localhost:9001/?a=x&b=y&c=z
Request to the login page:
http://localhost:9001/Account/Login.aspx?ReturnUrl=%2f%3fa%3dx%26b%3dy%26c%3dz&a=x&b=y&c=z
Notice how Asp.net creates a new parameter ReturnUrl but still retains the original parameters while redirecting to the login page.
I have a situation where the initial url length is around 1000+ characters and after this redirection, it becomes 2000+ which is kind of going beyond some browser limits.
Is there a quick way (configuration/httpmodule etc) to prevent the automatic parameters forwarding to the login page? (I can manage the login page needing these parameters to be extracted from ReturnUrl.)
For anyone who is wondering about this issue, the issue happens even in a default asp.net application but I was able to implement a fix for it.
Following is the fix:
Implement an HttpModule; handle the EndRequest event and check for 302/unauthenticated request
We have to use Response.RedirectLocation for most steps below
Using HttpUtility.ParseQueryString, get collection of all parameters
Using HttpUtility.ParseQueryString, get collection of all parameters within ReturnUrl value
Except ReturnUrl, strip out all other parameters which exist in ReturnUrl value
Update Response.RedirectLocation with ReturnUrl and remaining parameters (none in most cases), Url encoding as necessary
This will ensure the Url now has only ReturnUrl and other parameters which aren't copied in ReturnUrl.
You need to ensure that the login page (Account/Login in above e.g.) does not use any of these parameters or if they do, you have code to pull those out from value of ReturnUrl.
Hope this solution helps anyone with similar situation.

Whats the difference between the following page transfer methods

What is the difference between the following:
Server.transfer?
Response.Redirect?
Postbackurl?
When should I decide to use which?
Server.Transfer tells ASP.NET to redirect processing to another page within the same application. This happens completely server side. This is more "efficient" as it happens on the server side but there are some limitations with this method. The link below describes some of these.
Response.Redirect actually sends a HTTP 302 status code back to client in the response with a different location. The client is then responsible for following the new location. There is another round trip happening here.
PostBackUrl is not a "transfer method" but rather an property that tells the browser which URL to post the form to. By default the form will post back to itself on the server.
Here's a good link: http://haacked.com/archive/2004/10/06/responseredirectverseservertransfer.aspx
Server.Transer() works server-side. It will reply to the client with a different page than the client requested. If the client refreshes (F5), he will refresh the original page.
Response.Redirect() replies to the client that it should go to a different page. This requires an additional roundtrip, but the client will know about the redirect, so F5 will request the destination page.
PostbackUrl is a property telling an ASP control where to go when clicked on the client. This does not require an additional round trip while keeping the client informed. If you can use this method, it's generally preferable to the other choices.
Server.Transfer:
Transfers request from one page to other on server.
e.g. Browser request for /page1.aspx
Request comes on page1 where you do Server.Transfer("/page2.aspx") so request transfers to page2 And page2 returns in response but browser's address bar remains showing URL of /page1.aspx
Response.Redirect
This statements tells browser to request for next page. In this case browser's address bar also changes and shows new page URL
PostBackUrl
You can mention it on Buttons or Link buttons. This will submit the form to the page provided. It is similar to the:
<form method="post" action="/page2.aspx">

How to know if the current Servlet request is the result of a redirect?

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.

asp.net way to last URL from codebehind

is there a way from a asp.net-page code behind with "Request.Redirect()" or another method to redirect to the last page (like Javascript history back)?
You can check the Request.UrlReferrer property, which will be set if the user has navigated to the given page from another one. This is nothing more than the HTTP Referrer header that a browser will set. This will be null if the user navigates to your page directly.
HTTP is stateless, so theres no way of being able to read the browsers history (on the server) in the same way that Javascript can (its client side).
However there are a couple of tricks you can use:
Javascript could write the URL into a textbox which gets submitted to the server
The last URL visited could be stored in session - which can be retreived on a later visit
If using the URL in session method, you'll probably want to code this into a HTTP handler (not module) and this will fire automatically on every request.
Obviously these will only work if the user has previously visited a page, and not directly.

Resources