IIS and Multiple websites

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

I've created a demo version of one of our webportals, for use in showing the system to clients.

I found that when they were both listed under the same website, there was an issue with the session variables transferring between the two. This obviously raised concerns about security, since we're using userID and securitylevel variables to control access. It could feasibly mean that they could log into the demo site with supplied credentials, then switch over to the live site, and get in automatically, sicne it would see the appropriate security level.

In an effort to stop that, I moved the demo site off the default website, and created a new website on the Server in IIS, mapping it to port 82.

However, one of our clients is unable to access this, because their configurations are locking that port down.

I need a way I can set this up so that its accessible, but neutralise the session variable issue. Anyone got any suggestions (Without changing the session variable names - that would require too much work to set up and maintain as a copy from the live site)?

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

Do the websites have 2 different names? Can't you change the hostheader name in IIS so it can distinguish between the 2?

Or change the port to 8081 or similar, if the users firewall allows http they should be able to use 8080, 8081..........

 

wha?

I've discovered that the two sites aren't set up as applications in the IIS properties. So they just seem to be virtual directories. There seems to be some talk online that not having the applications set allows transferring of session variables. Logic dictates that going the other way would bar the transferring.

Can anyone confirm this?

 

Unless I misread your first post, you have 2 websites in IIS on the same webserver. The webserver (presumably) has one public IP address. You want to be able to distinguish between the 2 websites on your server through IIS so that your customer can look at your test site.

In IIS this is done by creating a unique combination of IP address, hostheader name, and port number. By changing one of these values for each website you create a unique identifier.

Now because you have 1 IP (assumed), one port (80 due to customer) the last option you can change is the hostheader name.

So for site 1: www.site1.com
for site2: www.site2.com

and so on. This allows you to use the same IP and port 80 but for multiple websites.

The port 8080 thing may not work, but you can connect to a website by specifying the following

http://www.site1.com:8080 (when configured on port 8080)

8080 is an alternative http port and may be open at your customers end.

 

at the moment, we use site.com/applicationname to access specific sites. To try and get around the session variable thing, i'd moved it out the default website on IIS, and created a new one, so that now, to access it, you use site.com:82/.

Im guessing that setting up site2.com is going to require pissing about purchasing domain names and/or registering the address with the public dns stuff. I unfortunately only have access to the server in question (and can have ports opened on the firewall). Thats the limits of my reach, and I doubt I could arrange more, for just a demo version of the site.

might have to go to using 8080.

 

You could register the address with DNS but you have to wait for the propagation etc, plus you may have to pay.

If it's only for a demo you could try adding an entry to the host file on the pc that is connecting to the website. That would map the IP to the domain name for you.

EDIT: Explanation!

EG:For the new site in IIS call it www.newsite.com

Then in the hosts file on the user pc enter:

IP of your webserver www.newsite.com

The host header is carried in the http traffic to the webserver, so when IIS reads it, it should send it to the right application.

 

As long as you're using your present setup you're going to have the problem you described. As far as any web server will understand any time you use one domain name with separate directories for different sites it is all one site.

Think about it. You're just serving files from multiple directories as far as the web server is concerned, and that is a very common occurence. There is nothing there telling it to separate the two the two directories.

 

When I started working where I am they were trying to use virtual hosts and wondering why things wouldn't work correctly. It was their directory structure for the web sites. They were nesting the sites one inside the other and as far as Apache could understand they were all one big site.

 

Provided you have a spare publicly-routable IP address in one of your ranges you should be able to give a separate private internal IP to the webserver, configure IIS to use that IP for the test site then NAT the traffic inbound to that private IP using the spare public IP. If you don't, then port translation is your only real solution, and that will rely on the person accessing the site allowing traffic outbound on the port you specify. I wouldn't use 8080 or 8081 btw, because the reason most places allow traffic out on those ports is because that is the port used by their proxy server - if their firewall admin is worth their salt then that port number will usually only be allowed outbound from their proxy server, rather than from their workstations. Best solution if you have to use PAT would be to get the third party to speak to their firewall/security guys about creating a policy that permits access to a specific IP address outside their firewall on a specific port.