We are experiencing odd behavior with our web application. If I change the URL to uppercase, or parts of it, after authenticating with the app, I then have to re-authenticate. Here's an example:
https://host.domain.com/website/asp
If I copy and paste that URL into a new tab after authenticating it will automatically authenticate and bring me to the landing page. However if I paste this into a new tab, while another tab is already authenticated:
https://host.domain.com/webSITE/asp
I have to re-authenticate with the app. (or IIS, this I'm not sure about)
This poses a problem when objects are developed without case being a consideration and I would think this behavior wouldn't be desirable. I will be reaching out to the application vendor but I'm wondering if anyone has experienced such an issue with IIS 7.
Thanks,
Max
IIS is generally case insensitive. Where sensitivity comes into play is with integrating modules. Modules like rewrite can be case sensitive. You didn't specify, but is your IIS application using rewrite at all? Also, your vendor may have controllers that are doing case sensitivity checks. But my guess would be the actual browser to be the culprit. Browsers that base cookies on the URL path can make those cookies case-sensitive. See this link for more information on users that have reported the same problem.
Related
I have a few ASP.NET sites running on one IIS server, of course using different ports. The sites allow for logging in via forms authentication. Session state is stored on a local state server. My problem is that when a user logs into one sites and then navigates to another, they get an exception from the second site and have to close/reopen their web browser to be able to access it. My guess is that the cookie from the first site is making it appear that they're logged in on the second one as well (though I could be completely wrong about this).
I've tried a few things to fix it (which are probably dumb and have nothing to do with the problem, but I'm far from an ASP.NET expert) including:
1) giving the sites different cookie names in Web.config's sessionState tag, and
2) Moving the sites to different app pools, but the problem persists. Any help would be appreciated.
I'd recommend setting up different domains for each site. If this is local, use the host file to route local.site1.com and local.site2.com to the correct place. Obviously you'll have to keep the port. Then you should be setting cookie with a different domain for each site and not causing the confusion.
I'm trying to create a .net web page that uses UserPrinciple.Current to get details of the currently logged in user, and allow them to change their Active Directory password.
After a fair bit of head-bashing, I got it working (yay!). My only issue is that I want it working on our intranet site (http://intranet) but it only seems to work if I specify the fully qualified domain name (http://intranet.mydomain.co.uk).
Looking at this page (How to configure an ASP.NET application for a delegation scenario) the troubleshooting section at the bottom of the 'Summary' section seems to contain two conflicting pieces of advice:
3.For Kerberos to work correctly, you must use fully qualified domain names (FQDN) for all the communication.
5.If the Web server uses a fully qualified domain name, you must add the site is added to the list of intranet sites in Internet Explorer.
Note that item 5 starts with IF - suggesting that it doesn't HAVE to do so. But Item 3 states that a FQDN is necessary.
So the question is simple: can I set up delegation through IIS 7 without using a FQDN host name ?
You need both otherwise it won't work for a good reason and IE will fallback to NTLM. Jus a side-note, it is really pointless to write a webapp where a user can change his AD password. This should be done through the Windows change password dialog and not some third party tool.
I have an ASP.NET page hosted on IIS6 running in windows 2008 server. The page has two iframes both calling to pages within the same application.
When viewed in the browser (IE8, compat mode) the session gets lost within the iFrames.
IIS is setup with a virtual directory of "App", so the website is accessed via http://localhost/App.
The problem occurs if you type into the browser http://localhost/app - note the change of case.
As far as I was aware URLs are always case-insensitive, but in this instance it clearly in not. After some testing, it turns out that the important factor is that the URL typed into the Browser must have exactly the same casing as that of the URL on the iframe. Or at least the casing of the virtual directory between the two URLs.
So a simple fix is to make sure you always use exactly the same url casing in the browser as is used on the Virtual Directory, but this is a bit difficult with users.
I've thought about rewriting the URL and doing some string manipulation to make the URL of the iFrame match that of the browser, but it seems a bit hacky and potentially unreliable.
Has anyone else experienced this or is there are simply IE config I can change?
Thanks,
Urls are case sensitive. It's IIS & ASP.NET that are not case sensitive when handling request urls, but the case sensitivity you're seeing for cookie paths should be true for any browser you use. This is not something you're supposed to change.
A workaround would be to redirect requests with a wrongly cased url to the correct one. You could write an IHttpModule for this, or, if you're using IIS7, use the optional Application Request Routing module.
I have an ASP.NET web site that responds with multiple skins depending on the domain that it is accessed via.
The problem is that authentication and some other features seem to suffer random glitches where the user is sent back to the log in screen, or other session controlled values appear to have been lost - but only when accessed via one of the domains. The other domain does not suffer the same issue.
On our test system, the issues DOES NOT exist when accessing via any domain. On live, the issue will happen at varying times during the session, even with identical steps followed. It is for these reasons that I don't think it is a bug in the application software.
On the live system, where the issue is, two websites are set up in IIS, each with bindings to the required domain. One accesses the site through a virtual directory at http://mysite.com/myvirtualdir, the other accesses the site at the root path at http://myalternatesite.com/. I don't think that the virtual directory is the issue however.
I've now solved my problem, though still not sure what the exact cause was.
I opened up website properties for the two websites in IIS, the one that worked and the one that didn't and compared properties.
For anyone else trouble shooting this issue, these are the steps that I took, in order of how likely I think they were to be the cause of the issue.
Second website was using Default app pool. There is nothing particular about the Default app pool settings on this server that would cause session to be lost from what I can see, but I have now changed to use the same app pool as the site that was working all along.
Disabled windows authentication to match the working website.
Changed default documents so that only the required document was listed.
Limited connections to 500 to match the working website.
Hope this is of use to somebody else.
I have the following setup:
http://www.example.com/dir1/ and
http://www.example.com/dir2/
Each virtual directory is configured on IIS6.0 as an application with own AppPool.
When redirecting authenticated user from dir1 to dir2 using response.redirect I lose authentication information for the user and the user is being redirected to the login page. This issue was not coming up with each app (dir1 and dir2) were configured under subdomain, ex:
http://dir1.example.com and http://dir2.example.com.
I have resolved the issue by adding a machine key to the machine.config file.
Can someone explain to me why it's not working on a http://www.example.com/dir1 configuration?
I regularly configure applications this way. There are a few places you can go astray.
Each web.config must have an exact duplicate of a common machineKey section. E.G. generate one section and paste it into all web.configs that you want to share FormsTickets with.
Each MembershipProvider (and Roles/Profiles etc) element must share the same applicationName attribute. By default this is '/' so unless you have manually changed it there should be not problem.
All providers in all applications must share a common connection string to a common aspnetdb instance.
If you have tried any of these steps individually or incrementally it is likely that the DB is in an inconsistent state. Ensure that each of these requirements is satisfied and start with a fresh database.
If you follow these steps you should have no problems. This is a fairly common and straight forward use case.
Let me know if you have any more questions.
I don't know ASP , but my guess would be that you're not specifying a path for the session cookie you're using, so the path setting will default to the path the cookie is being set in, /dir1 and /dir2, respectively.
When using subdomains, you probably used example.com as the main cookie domain, so it was accessible to both subdomains = no problem.
You should be able to find this out by examining the session cookie in your browser (e.g. in the "Cookies" tab in Firefox's Web Developer Toolbar).
If I'm correct, you will need to specify / as the path for the session cookie somewhere.
I don't know at which point to fine-tune that, but maybe it points you into the right direction.