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.
Related
I have very strange problem. I use ZfcUser as authentication module. I made a lot of projects on lot of different environments using ZF3 and ZfcUser module. I have nevere experienced such kind of problem which I will explain bellow. In my current project I cant login into system on production server. I succesfuly log from local env, or other test environments.
I try to investigate whats going on. I went to login page on production, entered my credentials and system redirects me to home page. No errors, no warnings... notihnig. But I was not logged in. I check the identity from the framework (identity()) - it was null. I thought that may be it is server issue with the php sessions. I checked the sessions on server. It appears that the problem was not there.
The framework succesfully stored the data it needs in sessions. I found the Zend_Auth key, the identity key and the value for logged user. It seems that with php sessions everything is OK.
I am powerless and cant even think about what is going on here and where is the problem. No errors are thrown. I trace the execution of code on local and production environment. Everything is same. The frameworks seems to work properly. But the IDENTITY is allways null
Found the problem.
So, the site was runing under a subdomain. Let say sub.domain.tld. This site is different from main domain which is domain.tld. In the programm code, the favicon of application was requested form the domain.tld not from the sub.domain.tld.
As a result when you hit the http://sub.domain.tld the browser stores two PHPSESSID cookies. One under sub.domain and another under domain.tld which couses Chrome to messed up
Interesting is that, Firefox and IE didnt messed with the sessions and the site was working porperly. I dont say that Crhome is guilty. Obviously the programm code was cousing the problem. But Chrome recognize that one domain is sub domain of the other
Thats why, when I was trying to run project on different environments as local setup or different domain e.g. test.different-domain.tld, ther were again two PHPSESSID cookies set, but in this time Chrome didnt messed up with the sessions becouse test.different-domain.tld is not recognized as subdomain of domain.tld
Very small and silly mistake, but cousing big problems
In an upcoming version of a currently-in-development webapp, I need to serve multiple domains from a single site. The code on the site will recognize the individual domains and vary the content accordingly. I do not know all of the domains that we will be serving, as clients can add new domains to their site. The coding parts, I know how to do - when clients add a domain, there will be a corresponding entry into our database and that will act as a key to control which set of content is shown.
The thing is, I suck at system administration. The server already hosts a dozen different sites unrelated to this webapp, so it's not a situation where every domain that hits our server's IP can go through the code I describe above. If I knew the domains ahead of time, I could simply point them to our server's IP and then create bindings in IIS to handle each. But since I do not know the domains ahead of time, I'm rather at a loss. What can I do to enable my IIS7 server to support this situation?
After looking around a bit, I have found a few options for this.
1) Building It Into The Code
Probably the best option is to programmatically create bindings in IIS6 and in IIS7. This way everything is integrated into the webapp, meaning there's no muss or fuss outside of the app. It requires a bit more work in the app itself, but the benefits of keeping things clean and keeping all the functionality around this action inside the single codebase are almost definitely worth it.
2) PowerShell
Another option is to set up a script for powershell to have it handle this stuff based on the script detecting changes to the database. This would work well also, but has the drawback of creating two codebases to maintain.
3) Remove Domain Bindings
This answer led me to try removing the existing domain from the webapp's bindings in IIS. Making this change resulted in being able to reach my webapp by just visiting the IP address (so the binding was no longer an issue). And the one domain we have set for this webapp so far still reached the desired site as well. So it seems that the solution could be as simple as to have no host/domain listed in the bindings on IIS. As long as only one site does this, all traffic that does not match another binding loads that site. A big upside here is that it takes less time/effort than any of the coding solutions mentioned above. The downside is that you can only have one site on the server perform this way, and you can no longer have the server locked to only serving content with recognized domains.
Is it possible to add a extra ip address to the server?
This way you could let the IIS process all request on this IP address and run your logic for these request only. leaving the existing websites untouched.
i have a web site that uses forms authentication. the problem is that i have the site installed multiple times on the same production servers because i need to have a few different login pages (based on the domain in this case). after the domain specific login page, the rest of the site is the same. obviously, this requires a lot of maintenance as each new version has to be installed multiple times on the server (with varying the login page in the web.config file).
so i thought is there a way to install the site on 1 folder on the disk, have a web site on the IIS take in all the needed domains and make some http module (or some other solution) in which i could give it a list of domains and the forms authentication for that domain. this way make the login page used by each site change according to the domain while still having only one site to maintain on the server.
Thanks
Dani Avni
I have seen this go a number of ways and a lot of it depends on how you have things setup in IIS.
If all domains are on the same IIS website the most common solution would be to create a httpmodule, or even an actual .aspx page, that loads configuration and based on the requested URL send the user to the right login page. You could even do a "Server.Transfer()" if you want the users URL to stay the same. Then in the web.config you still set a single login page. Just make sure that each other login page allows anonymous users access.
If all domains are separate IIS sites, i would recommend at that point just maintaining different copies of the sites. But the real question is why you need different logins.
My workplace has a couple of web applications that do exactly what you are trying to describe. There are a couple of approaches we have used, depending on the situation.
The more common approach we use is to have all the actual sites on IIS point to the same directory. The logic for the login gets the URL, determines which client site is being requested, and takes that into account on login. The actual login page is the same for all client sites, though, so it's just determining which database to use.
If you want to do anything fancier than that, another approach we have used is to create our own MembershipProvider, at which point you can basically do whatever you want. You should have access to HttpContext.Current if your class is being called by the ASP.NET authentication provider (you would set the membership provider in Web.config to your provider).
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.