I have an ASP.Net application which generates short url for sharing. I want to track the url from where (source) click occured when it hits my asp.net page. I tried using Context.Request.UrlReferrer.AbsoluteUri but all I get from it is null.
Any ideas?
TIA
Don't forget that the referrer will sometimes be null for things like search engines, or people behind corporate firewalls that remove some HTTP headers.
Not quite as clean, but you could use Request.Headers["Referer"]. Should be the same as using Context.Request, but I've found the behavior to be different.
Related
I have to make all links SEO friendly on our website.
I have the following url: http://newark.storeboard.com/board.asp?RegionID=353&ClassAdCatID=740&IsEvent=1&IsCoupon=0&IsBlog=0
I need it be: http://neward.storeboard.com/classifieds/events/ConcertsLiveMusic
I have no way of accessing the IIS so this has to be done thru code. Any ideas about how to achieve this would be greatly appreciated.
Many Thanks,
Paul
The standard way of solving this as far as I know is to use a rewrite engine in IIS (such as ISAPI_rewite or IIS7 url rewrite module)
However, you don't have access to IIS you say... That makes it tricky. Two thoughts come to mind:
1) Could you create a dynamic (asp) 404 page that then looks at the request header and does a transfer according to the page requested?
2) Or, and this is rather lame, could you create a static folder structure that goes some way to looking like that url structure?
If you upgrade to IIS7 and use ASP.Net then you can control the URL rewrite module from your code.
I've done something similar to Matts suggestion 1 in the past and it can work. The important thing is you make the 404 page directly feed the true page content and not do a redirect. Otherwise your defeating the point of SEF URLs for SEO gain.
From the few references I still have to the code. asp has a Server.Transfer() function but you may have issues that you can't pass query string parameters. I think I ended up streaming the real page through the 404 page using the MSXMLServerXMLHTTP object and Response.BinaryWrite().
I have not found the same as or related to my question above.
If it is already asked, please let me know, I will delete mine.
I am learning asp.net mvc 2.
After downloading the rendered page, the visitors have a chance to manipulate the html contents ILLEGALLY and submit it back to the server. In MVC, how can I avoid this issue?
You cannot prevent anything on the user side. Therefore you must ensure that the server reacts correctly to manipulated input.
Note that the automatic model binding is tricky: both over- and under-posting can cause trouble.
This is an excellent post on that topic: http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html
Take all the efforts you can to validate the user input at the server. MVC offers the AntiForgeryToken which helps verify that the page being posted back is the correct page but as with any client-side verification, it's not foolproof.
You can't do anything about this.
Use the mantra "never trust anything from your users" and validate everything on server side.
I'm using the old 404-rewrite method on a certain site that is tied to IIS6 *.
So if I enter
http://example.com/non-existent/path
it calls my error page like so
http://example.com/catch.aspx?404;http://example.com/non-existent/path
Great.
Except if I call the page with a fragment, like
http://example.com/non-existent/path#with-fragment
I get the same result as above. I can't find the fragment anywhere:
Request.Url
Request.Url.OriginalString
Request.UrlReferrer
Request.RawUrl
headers, server variables, etc
This has come up because I want to resolve paths created by AJAX to their server-side versions.
Is there any way for me to retrieve the original path from my handler?
Thanks.
(*) Please don't suggest I change platform. Obviously I would if I could.
No, there isn't.
The portion of URL after # is never passed to the server per HTTP spec. Has nothing to do with platform.
To work with info after # in javascript you should look at Javascript History plugins/functionality. jQuery has history plugin, asp.net ajax and mvc ajax (partial views et al) have that. Mind you, it's not a very easy thing to implement, you have to get into undo/redo mindset.
It probably won't work if you are trying to handle 404's on the server - server doesn't know that there was something after #. Not sure what you want to do though, 404 handling, or "resolve paths created by AJAX"? What exactly is the goal?
I posted a query for 301-redirect using ASP.NET 3.5 here:
Redirecting default.aspx to root virtual directory
Based on the replies I got there, I realized there might be a bug in ASP.NET's Request.RawUrl method which is unable to return the actual raw url (without /default.aspx) when being used in a sub-directory, i.e. the /default.aspx page is inside a subdirectory.
Can someone please shed some light on this possible bug?
Thanks,
Asif
i found a good explanation here
http://codeasp.net/blogs/vivek_iit/microsoft-net/873/301-redirect-from-default-aspx-to-site-root
Thanks
If you suspect this is a bug, then the place to go is Microsoft Connect, where you can report and discuss the bug directly with Microsoft.
Edit: I was able to reproduce the look per your comments.
I was unable to reproduce the infinite loop, however. I injected code into the Global.asax Application_BeginRequest handler of a web application and got the expected behavior of a single redirect.
There are other, and IMO much better, options for handling global redirect rules. On IIS7, I use the URL Rewrite module to configure rewrite rules in IIS. You can read more about it and download it here: http://www.iis.net/download/urlrewrite. The appeal of a solution such as this is that you can customize and update your rewrite rules without recompiling the application.
Edit: I was able to retrieve the raw URL without the default.aspx (after the redirect) by using instead:
Request.ServerVariables["CACHE_URL"]
It's worth a shot.
Have you looked at the IIS settings for your virtual directory? If there is a default document set to default.aspx then this will explain the infinite loop that you are experiencing. You are telling the website to redirect to the virtual directory without the "default.aspx" and IIS is detecting this on the next request and putting it back in ad infinitum.
Right click your virtual directory, select Properties and then the Documents tab. If default.aspx is in the list then that is what you will get. The Url of the request will be passed to the ASP.NET worker process as /folder/default.aspx rather than /folder/
This is not a bug. If IIS didn't do this, you would get a page not found error.
Sounds to me like you need to investigate URL rewriting: http://msdn.microsoft.com/en-us/library/ms972974.aspx
I have an ASP.Net 3.0 SP1 app that uses Form Authentication.
While testing, I noticed that if I viewed a page that another user was viewing, the other users name would be displayed in the control on my master page. The Context.User.Identity is also for the other user.
If I switch to different page that no one else is viewing the Context.User.Identity is correct.
I stumped and would appreciate suggestions.
Thanks in advance.
Chris
Maybe because output caching is enabled for the page: if the page is cached server-side with VaryByParam=none, all users will get the same copy from the cache.
I can only think of two things that can cause this:
You're storing user-specific data in a place shared between requests (e.g. in a static(C#)/shared(VB) variable, in the ASP.NET Cache, in the Application object, ...)
You have output caching enabled.
Check for:
OutputCache directives in your aspx and ascx files,
system.web/caching element in your web.config file(s),
Calls to the HttpCacheability.SetCacheability method.
If you can't find the problem:
Try creating a simplified version of your application until you get the simplest possible version that still reproduces the undesirable behaviour.
During this process of simplification you'll likely discover the problem for yourself. If not, post some code from the simplified version.
Make sure you are not using a link that comes with the authentication ticket when using a cookieless browser.
Also make sure to review any other that might be sharing the data among requests. Just like DOK said, but remember Application isn't the only way you could be doing that.
It looks like the issue was caused because I setting targetframe="_self" or Target="_self". I removed all these and everything seem to be working fine.
One other note: If I were to refresh the page it would also display the page with the correct user.