I was just wondering how in I can find the previously visited url for a session?
So after a user does something I can redirect them to that URL.
Is there any standard way to do this? Otherwise I was going to add some overrides to Global.asax and use a session variable to store URL history.
Request.UrlReferrer might be what you want, but you might want to think about using AJAX or passing the url as a parameter...
The above answer is totally correct, although in certain cases you cannot pass the URL along the query string, for instance when the URL is masked. In this case the right way is Request.UrlReferrer. The problem with using a session variable is it might expire and cause unreliable behavior. Or if you have more than one session active or mirrored servers, it wont work at all.
In general its a poor idea to use session variables in MVC when it can be avoided. The solution I went with was using JavaScript to get the previous URL and passing that up in the view model.
Related
Similar questions have been asked about the nature of when to use POST and when to use GET in an AJAX request
Here:
What are the advantages of using a GET request over a POST request?
and here: GET vs. POST ajax requests: When and how to use either?
However, I want to make it clear that that is not exactly what I am asking. I get idempotence, sensitive data, the ability for browsers to be able to try again in the event of an error, and the ability for the browser to be able to cache query string data.
My real scenario is such that I want to prevent my users from being able to simply enter in the URL to my "Compute.cshtml" file (i.e. the file on the server that my jQuery $.ajax function posts to).
I am in a WebMatrix C#.net web-pages environment and I have tried to precede the file name with an underscore (_), but apparently an AJAX request falls under the same criteria that this underscore was designed to prevent the display of and it, of course, breaks the request.
So if I use POST I can simply use this logic:
if (!IsPost) //if this is not a post...
{
Response.Redirect("~/") //...redirect back to home page.
}
If I use GET, I suppose I can send additional data like a string containing the value "AccessGranted" and check it on the other side to see if it equals this value and redirect if not, but this could be easily duplicated through typing in the address bar (not that the data is sensitive on the other side, but...).
Anyway, I suppose I am asking if it is okay to always use POST to handle this logic or what the appropriate way to handle my situation is in regards to using GET or POST with AJAX in a WebMatrix C#.net web-pages environment.
My advice is, don't try to stop them. It's harmless.
You won't have direct links to it, so it won't really come up. (You might want your robots.txt to exclude the whole /api directory, for Google's sake).
It is data they have access to anyway (otherwise you need server-side trimming), so you can't be exposing anything dangerous or sensitive.
The advantages in using GETs for GET-like requests are many, as you linked to (caching, semantics, etc)
So what's the harm in having that url be accessible via direct browser entry? They can POST directly too, if they're crafty enough, using Fiddler "compose" for example. And having the GETs be accessible via url is useful for debugging.
EDIT: See sites like http://www.robotstxt.org/orig.html for lots of details, but a robots.txt that excluded search engines from your web services directory called /api would look like this:
User-agent: *
Disallow: /api/
Similar to IsPost, you can use IsAjax to determine whether the request was initiated by the XmlHttpRequest object in most browsers.
if(!IsAjax){
Response.Redirect("~/WhatDoYouThinkYoureDoing.cshtml");
}
It checks the request to see if it has an X-Requested-With header with the value of XmlHttpRequest, or if there is an item in the Request object with the key X-Requested-With that has a value of XmlHttpRequest.
One way to detect a direct AJAX call is to check for the presence of the http_referer header. Directly typed URLs won't generate a referrer, but you still won't be able to differentiate the call from a simple anchor link.
(Just keep in mind that some browsers don't generate the header for XHR requests.)
Recently I have been asked by a client to log into a legacy site using POST and not GET (from a 3rd party site), All of the needed variables are now sent within a post instead of a query string.
The problem is that upon receiving all of variables they are stored into Session and then redirected to the correct page within the application (from the logo-in Page).
While this works perfectly while calling the page using GET, a POST call will lose all of the Session variables after
Response.Redirect(#"~/SOMEPAGE.aspx",false);
Another thing that is odd is that the Session ID will remain the same but all values will be gone.
When Using Server.Transfer the session is intact but will be lost once the Response.Redirect is used. (there is no option to change all of the code.)
Does any one know of a way to resolve this or some sort of a work around that might be used.
Thanks!!!
There are a few reasons this could happen.
You are using Session.Abandon() in your code
You are switching between a secure (https://) and insecure (http://) URL
You have some code in your global.asax that is manipulating Session, or the .Secure or .Path properties of your Response.Cookie
edit http://forums.asp.net/t/1670844.aspx
I have a scenario where the website user have a filter-bar, to set what content they want to see on the website. After selecting the options the user clicks on the .net submit linkbutton.
The problem is that I want to reload that current page, but I am using Friendly Urls, Intelligencia.UrlRewriter, so I can't use :
Request.Url or Request.ServerVariables.Get("PATH_INFO");
I have managed to use Request.UrlReferrer , but this may occur null in some cases (even though I am checking for null I don't want to use this solution).
Is there some unique/specific way of solving my problem?
You can use Request.RawUrl to get the original url. (The one the user sees in the browser).
you can try this: Request.ServerVariables("HTTP_X_REWRITE_URL");
I don't know about Intelligencia.UrlRewriter but it works with helicon ISAPI_Rewrite http://www.isapirewrite.com/
I wanted to know if there is a solution using IIS6 for an application to get rid of the default.aspx text in the url. so for example if a user hits:
www.website.com/default.aspx
the browser only shows:
www.website.com/
No matter what.
It's just for SEO.
I already use UrlRewriting.NET for some rewrites in my app but for I'm not that clever to create a rule for that.
Any help is much appreciate.
Thanks.
Jose
I think ScottGu already has the topic of rewriting in ASP.NET covered: http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx.
He covers things such as:
Rewriting using UrlRewriter.net, ISAPI Rewrite
ASP.NET Tricks, posting back (hitting the friendly version of the url)
With your problem I think you need to use a combination of, never linking to 'default.aspx' ie. ONLY link to '/'. Then use Scott's Form Postback browser file to ensure postbacks always hit that same friendly version of the url.
Redirecting 'default.aspx' to '/', which then gets served by 'default.aspx' sounds like a recipe for disaster to me. Just fix your links to ensure you never end up on 'default.aspx' explicitly.
I think the simplest way to change the search results index (assuming it knows about HTTP 301) is to write a little function in your default.aspx's Page_Load that redirects the browser using a 301 Moved Permanently (or 302 Moved Temporarily).
void Page_Load(...) {
if(Request.Path.EndsWith("default.aspx", true/*case-insensitive*/, null)) {
Response.StatusCode = 301;
Response.StatusDescription = "Moved Permanently";
Response.Headers.Add("Location", "/");
HttpContext.Current.ApplicationInstance.CompleteRequest(); // end the request
}
// do normal stuff here
}
If you have something to do URL rewriting, then all you need to do its ensure that your links point to the correct URL.
If you don't fix your links, its up to the browser to decide if it wants to display the actual link it requested.
If you would really like to do a dodgy job, you can use some javascript to make the address bar of the browser display whatever you like, even if its invalid.
If default.aspx is set as the default document to serve in IIS, and all your internal site links contain URL's without the default.aspx then I think that should do the trick.
Although the user can still type in default.aspx, search engine spiders should just pick up the friendlier URL's from your link href attributes.
The way I would do it is to use Application_BeginRequest in public class Global : System.Web.HttpApplication and check the HttpContext.Current.Request.URL for default.aspx, and then use HttpContext.Current.Response.Redirect from there if you find it.
The downside is having a redirect is not always so great and this isn't going to work if you are posting data to that default.aspx page. But you can't simply trick the browser into showing a different url, though you can tell ASP.NET to serve whatever page you want for any request.
In an aspx C#.NET page (I am running framework v3.5), I need to know where the user came from since they cannot view pages without logging in. If I have page A (the page the user wants to view) redirect to page B (the login page), the Request.UrlReferrer object is null.
Background: If a user isn't logged in, I redirect to the Login page (B in this scenario). After login, I would like to return them to the page they were requesting before they were forced to log in.
UPDATE:
A nice quick solution seems to be:
//if user not logged in
Response.Redirect("..MyLoginPage.aspx?returnUrl=" + Request.ServerVariables["SCRIPT_NAME"]);
Then, just look at QueryString on login page you forced them to and put the user where they were after successful login.
UrlReferrer is based off the HTTP_REFERER header that a browser should send. But, as with all things left up to the client, it's variable.
I know some "security" suites (like Norton's Internet Security) will strip that header, in the belief that it aids tracking user behavior. Also, I'm sure there's some Firefox extensions to do the same thing.
Bottom line is that you shouldn't trust it. Just append the url to the GET string and redirect based off that.
UPDATE: As mentioned in the comments, it is probably a good idea to restrict the redirect from the GET parameter to only work for domain-less relative links, refuse directory patterns (../), etc. So still sanity check the redirect; if you follow the standard "don't use any user-supplied input blindly" rule you should be safe.
If you use the standard Membership provider, and set the Authorization for the directory/page, the code will automatically set a query parameter of ReturnUrl and redirect after a successfull login.If you don't want to use the Membership provider pattern, I would suggest manually doing the query string parameter thing as well. HTTP referrers are not very reliable.
The problem could be related on how you redirect the user to some other page. Anyways, the referer url is nothing you should take as absolute rule - a client can fake it easily.
What you're looking for is best done with a query string variable (e.g. returnURL or originURL). Referrer is best used for data mining operations as it's very unreliable.
See the way ASP.Net does redirection with logins for an example.