In IIS 6, I need to allow multiple domains to come through to a single website so that they can all share the same master page and database. They would all have a uniform look. I own a separate domain name for each site. I need to know what is the best way of accomplishing this. I have read about ISAPI rewrite but don't really understand how that works. I have also considered just having a redirect statement based on the url. The websites each share the same purpose, but each one site is for a separate company.
It sounds like you want to use host headers. One site can "answer" to many domain names.
Using Host Header Names to Host Multiple Web Sites (IIS 6.0)
Related
I have a couple of web apps in azure (same codebase, in different regions) that I need to set up as end points in Traffic Manager.
One of those sites is already Live. It is configured to support multiple domains, but all requests are 301 redirected to a specific domain, for SEO reasons. The other site needs to work in the same way of course, within the Traffic Manager setup.
The issue is that Traffic Manager needs to be able to ping the *.azurewebsites.net domain and receive a 200 response to work, but with the current redirect rule in place on the endpoints, this will not work.
If I remove the redirect rule then Traffic Manager will work, but it means that requests for the sites at *.azurewebsites.net will not be redirected (and so presents an SEO concern).
The solution I'm heading towards is serving up a different robots.txt file (with a Disallow: / rule) if the request is for the azurewebsites.net domain. Is this feasible? How might I go about doing this?
Are there any other ways I could make this work?
thanks
I'm going to rework the current redirect rule so that it doesn't redirect for one particular path on the azurewebsites.net domain (*.azurewebsites.net/favicon.ico), which should enable Traffic Manager to ping the site, whilst keeping SEO ok for the rest of the Urls.
7 years later and some months, the answer seems to be in the traffic manager's config under other expected codes, so you can add 301-302 to that list to make your host health show online.
Can anyone think of a neat solution for this; we operate an website service and sell to large organisations. Rather than have a logon for everyone, we'd like to be able to provide a direct link to our website from the organisation's Intranet page. We'd then like to check the referrer and if it's in our listed of 'trusted referrers', i.e. the intranet url, then we grant logon without asking for credentials.
I'm aware you can do $_SERVER['HTTP_REFERER']; to get the referrer, but I'm also aware that can be spoofed. Can anyone think of how we could achieve what we want, but while also guaranteeing it won't be hackable?
Thanks in advance
It's not exectly what you want, but to make logging on easier and ensure you don't need to store all the passwords you could use, for example, OpenID.
I think that there is no perfect and safe solution for this.
One solution would be to append tokens to the urls. It will work and it will be save, but anyone who knows the link (including token) will be able to login as that organization
Another solution would be to check the source ip. This can be done in different ways *apache, load balancer, app, etc).
Also a combination of token + ip could work (this token for that organization but only if the request comes from allowed_ips for that organization)
A more elegant solution (which I implemented for several big companies) would be to integrate you website login with the active record domain login. It is possible to use the current user window login as login into a website, using domain authorization. If a user is logged in into a domain, when enters your site will automatically login to the website.
This solution is much more easy to implement than it sounds. But, requires Active directory and workstation that connects to a domain to be in the company (this shouldn't be a problem, most of corporations are using windows on workstations and active directory for domain controller). Also is working best on IE only (direct login to the website). On other browsers the domain login popup will appear and user will have to enter again the domain password.
Also, I am pretty sure that can be made to work on linux environments, but I have no idea how.
Background
I work at a SaaS company where you get a site when you signup.
If the company's url is saas.com this could be a list of clients:
abc.saas.com
mysite.saas.com
so.saas.com
Currently, each of our clients has to go to /admin to get to his admin panel.
abc.saas.com/admin
mysite.saas.com/admin
so.saas.com/admin
The thing is that services like Clicktale that track users by recording them, limit the amount of subdomains you can track. If you want more subdomains, you have to pay more.
Because of this we are analyzing the possibility of migrating to admin.saas.com as a single subdomain for all admin panels.
Which are the pros and cons of having several /admin subdomains VS a single admin subdomain?
Considerations
SSL is already solved, we have a wildcard certificate
We could keep a 301 redirect from /admin to the admin.saas.com
Thanks!
Pros to have a single domain (admin.saas.com):
Users having more subscriptions can manage subdomains much easier (they don't have to navigate to a different URL)
Your documentation and videos will be easier to understand with a specific address. Links with placeholders like {yourdomain}.saas.com/admin make clients think.
Firewall rules could be set up easier in a complex architecture
We had to make the same decision while developing our SaaS/PaaS product few months ago and we are happy with this implementations. According to your scenario, I cannot see any cons.
I have a requirement where I need to implement SSO between two different websites.
One of the website say www.abc.com is written using ASP.NET and is hosted on IIS 7.0. The second website say www.xyz.com is written using PHP and uses Apache web server. Both the websites uses different databases and uses different algorithms to authenticate the user.
I cannot use a third party SSO as that would mean changing the authentication for both the websites. Wanted to know if this is possible and if yes, what should be the approach?
Thanks in advance...
We could find an alternative approach. Basically, we were trying to address this issue by using two cookies (one each for www.abc.com and www.xyz.com created by each site), but since we were unable to find a way for reading cross-domain cookies, we were stuck up.
But then, I stumbled upon the way forums.asp.net and hotmail works. They use the live.microsoft.com to set the authentication cookie.
Now, we plan to create a third website for authenticating the user. The login forms in both the www.abc.com and www.xyz.com will call the third website to set the authentication cookie. Using this authentication cookie, we will be able to allow user to have seamless browsing across both the websites.
Also, found a very good article on this implementation.
http://www.codeproject.com/Articles/114484/Single-Sign-On-SSO-for-cross-domain-ASP-NET-applic
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?