I suspect the answer is no (or at least, not in an intelligent manner), but felt like asking.
Is it possible in an asp.net HttpModule to determine the page that is going to be returned to the user, taking default page settings of IIS into account (without hardcoding them outside of IIS). For example, if a user requests http://www.example.org/bar/, the real page might be http://www.example.org/bar/index.html -- but could just as easily be http://www.example.org/bar/foot.html , depending on the user's IIS settings.
You're correct: in cases where there was no file.ext available in the requested URL, the IIS settings would have to be available in order to determine the actual page that was returned.
Given that the module has to live on the IIS server, I think you could get the list of default pages configured in IIS by connecting via WMI. You'd then have to get the list of files in the requested folder to figure out which of the default pages was actually returned.
Related
Is there a way to limit access to a particular page with IIS? basically what I'm looking for is to only allow access to a particular page via another specific page/link. I've looked into the IP Address and Domain Restrictions feature within IIS and can utilize that, but I would like to keep it between particular pages.
for example:
I have a page, SecurityCheck.aspx and I only want a person to be able to access that page if they came from SecurityPassThrough.aspx.
Since I don't know your experience level I think it's worth pointing out that what you're trying to do would not truly be a secure solution. Anyone is capable of modifying their HTTP request headers before sending them to the server.
If this faux security is good enough for your purposes, then you could implement it simply by checking the Request.UrlReferrer property. As far as I know there is no way to do this type of processing out of the box in IIS, so you're left going down the stack to the ASP.NET level:
if (!Request.UrlReferrer.Segments.Contains("SecurityPassThrough.aspx")) {
//Do something
}
We have a web application, say mysite.com.
Now users can come and create pages like, mysite.com/page/mypage. Here 'mypage' is unique identifier for the page he/she has created. So whenever mysite.com/page/mypage url is requested, it hits our 'pagerequestservlet', which gives out requested page data.
Now what I want is, whenever user hits, mypage.mysite.com, then also we give out the same page related info (that we give out on mysite.com/page/mypage). This would mean, I need to make all my *.mysite.com requests to be handled by 'pagerequestservlet' (or a similar servlet). Then I can just parse the request URL, identify the identifier 'mypage' and return the data.
Now my question is, how to make all my *.mysite.com requests to be handled by 'pagerequestservlet'? I am using GoDaddy as my domain registrar.
You must setup your DNS to allow such wildcards, I don't know wheter GoDaddy supports this.
A servlet is "DNS-agnostic", normally it does not need to know anything about its domain name. This way it's possible to deploy the same servlet on different environments or even with different context roots (example.com/a and example.com/b).
You still have access to the domain name via ServletRequest#getServerName(). You could implement a Filter that handles the subdomain part and redirect to the correct page. But be aware - if you run in a clustered environment or behind a load balancer, this would not return mypage.example.com, but the name of the host ther servlet was deployed to.
Imagine a Web Forms application with routing.
A clean page name like:
http://www.mywebsite.com/home
Might have an underlying of URL of:
http://www.mywebsite.com/page.aspx?id=3
If a user enters http://www.mywebsiter.com/page.aspx?id=3 into a browser, I need to redirect to http://www.mywebsite.com/home
Is this possible to do?
I can't work out a way to do this as the routing engine is not executed for a physical page and in the page.aspx Page_Load method I have no way of knowing whether the URL was entered directly or was the result of a route.
You can use the Page.RouteData.Values collection to detect if the page is being loaded due to routing, rather than a direct URL. That can be done in Page_Load().
If there are route data values (you would likely check for values that you would know should exist), then they are fine. If there are no route data values, the page has loaded 'directly', and you should redirect them.
Check out the IIS URL rewrite module.
You could also look at things like disabling routing for files (RouteTable.Routes.RouteExistingFiles = false;) - that could be dangerous though!
Is there a way to access referrer information from the server log in a ASP.NET web application?
I would like to know if a customer comes to my web app from a specific site and change the app's behavior accordingly. I could have the webmaster of the other site include a query string, but to my knowledge this wouldn't work because as soon as Tom, Dick or Harry posted the link somewhere else, the query string would be unreliable.
Is there a sure fire way for a web app to know where the user came from?
Why not just check the Request.UrlReferer property and change the behavior if the referer is not any page on your site?
This would be a lot simpler than referencing IIS logs.
You can access the referrer information through the HttpRequest.UrlReferer object.
However you should note:
This can null - so check for null before calling AbsoluteUri on it.
This can be changed fairly easily, so you can't rely on it completely
Why would you not just access the Request host header for the HTTP_REFERER instead of the log file? See here, but note that you are never guaranteed to recieve this information, nor is it reliable if you do.
Request.UrlReferrer.AbsoluteUri
gives you the same as the server logs will. Probably a combo of querystring variable and UrlReferrer will do the best job of ensuring that it came from the right source.
UrlReferrer is sent by the client, and it's not guaranteed to be there.
Are you using a shared environment? Normally they will supply this if you request the logs (normally an option in Plesk or similar). The log directory will probably be one or two folders up from the root http folder, so it may not be accessible using the IIS user.
On a dedicated server then you can obviously configure this manually.
I implemented OpenID support for an ASP.Net 2.0 web application and everything seems to be working fine on my local machine.
I am using DotNetOpenId library. Before I redirect to the third party website I store the orginal OpenID in the session to use when the user is authenticated (standard practice I believe).
However I have a habit of not typing www when entering a URL into the address bar. When I was testing the login on the live server I was getting problems where the session was cleared. My return url was hard coded as www.mysite.com.
Is it possible that switching from mysite.com to www.mysite.com caused the session to switch?
Another issue is that www.mysite.com is not under the realm of mysite.com.
What is the standard solution to these problems. Should the website automatically redirect to www.mysite.com? I could just make my link to the log in page an absolute url with containing www? Or are these just hiding another problem?
Solve the realm problem that you mentioned is easy. Just set the realm to *.mysite.com instead of just mysite.com. If you're using one of the ASP.NET controls included in the library, you just set a property on the control to set the realm. If you're doing it programmatically, you set the property on the IAuthenticationRequest object before calling RedirectToProvider().
As far as the session/cookie problem goes with hopping between the www and non-www host name, you have two options:
Rather than storing the original identifier in the session, which is a bad idea anyway for a few reasons, use the IAuthenticationRequest.AddCallbackArguments(name, value) method to store the user's entered data and then use IAuthenticationResponse.GetCallbackArgument(name) to recall the data when the user has authenticated.
Forget it. There's a reason the dotnetopenid library doesn't automatically store this information for you. Directed identity is just one scenario: If the user types 'yahoo.com', you probably don't want to say to them 'Welcome, yahoo.com!' but rather 'Welcome, id.yahoo.com/andrewarnott'! The only way you're going to get the right behavior consistently is to use the IAuthenticationResponse.FriendlyIdentifierForDisplay property to decide what to display to the user as his logged in identifier. It gives more accurate information, and is easier than storing a value in the callback and getting it back. :)
I dunno how OpenID works, but LiveID gives you a token based on the combination of user and domain. I just would have forwarded www to mysite.com.
The cookies and sessions and everything else get lost between www.site.com and site.com. I don't have patience enough to thoroughly read all the specs, but http://www.w3.org/Protocols/rfc2109/rfc2109 states that
A is a FQDN string and has the form
NB, where N is a non-empty name
string, B has the form .B', and B' is
a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Note that domain-match is not a
commutative operation: a.b.c.com
domain-matches .c.com, but not the
reverse.
I think that means yes, you do need to forward to www. I have always added domain correction code to my sites when cookies and sessions are being used.