Dan: I can think of a few ways to accomplish what you've indicated, though the specifics of how you wish to use them is up to you.
OPTION A) I'm not sure what webserver you said you were using, but this is the kind of thing that is commonly done with "Virtual Hosts". You can setup a virtual host to be a domain name such as "abc.com" or "abc.xyz.com". The first requires DNS population (which takes about a day or so), and the second choice works fine as long as your local DNS is setup (because xyz.com is already associated with DNS servers elsewhere). Now, in your webserver (thinking of Apache here), you setup a virtual host. For apache it would be setup like this: <VirtualHost> NameVirtualHost abc.xyz.com:80> DocumentRoot /clients/abc/docs ServerName abc.xyz.com ErrorLog /clients/abc/logs/error_log CustomLog /clients/abc/logs/access_log common </VirtualHost> You can setup as many virtual hosts as you want, with no overhead concerns - it is the same as if someone is just hitting your site normally... no processing is being done on the backend. However, each virtual host is for request purposes a separate server, so the only way to share files between virtual hosts is to ALIAS common directories. In this manner, you might have a /images directory alias that points to "/common/images/" for all virtual hosts. OPTION B) Use <@CGIPARAM NAME="REFERER"> to catch the page the request originated from (what customers site did the link come from), and direct them to the appropriate page from there using <@URL>, not a REDIRECT (which will change the location bar). This is also fairly low on overhead, but the <@URL> may not always work as expected. OPTION C) The simplest and least technical solution (and the easiest to crack - if someone really wants to know what the URL is supposed to be), is to just do a frameset, and insert the path of the page you want in the <FRAME> tag with Tango. Of course anyone viewing the source of the frameset will see the URL, but if its not a security issue, just do that. FYI, If you are concerned about security, you can use a javascript encryption method (it encrypts the entire page, so that without the "key" - all anyone can see when they view source is the encryted page information and the javascript code that is used to decrypt it. All "encryption" methods are not the same. In some cases, all you are doing is converting your text into ASCII code - which is EASILY decoded. Look for something that actually uses crytography. An excellent example of something like this is http://www.hiveware.com/enkoder_form.php, which I actually use on my personal stuff to protect my email address from spam email harvesting. Anyway, hope this helps. Happy Coding! Jim Kass Web Developer -- Forestweb: The Source for Industry Intelligence Best Content -- Most Relevant -- Best Delivery http://www.forestweb.com (310) 553 - 0008 -----Original Message----- From: Rick Sanders [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2003 11:14 AM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: Looking for thoughts OK, Here's how it'll work. What's needed: 1. A physical or virtual directory of the domain: www.site.com/site1 2. Although it's going to www.site.com/site1 the URL must remain being www.site.com How it'll work: 1. You need to have a link somewhere that goes to www.site.com/default.taf?site=site1 3. You'll need a default.taf that checks the <@ARG site>, and goes to the appropriate function. <@IF EXPR="<@ARG site>=site1>"> <frameset rows="*,1" frameborder="NO" border="0" framespacing="0"> <frame src="refresh1.htm" name="mainFrame"> <frame src="nothing.htm" name="bottomFrame" scrolling="NO" noresize> </frameset> <noframes><body> </body></noframes> </@IF> 4. The refresh1.htm will have the re-direct: <meta http-equiv="refresh" content="0;URL=http://www.site.com/site1";> That's what I would do. Rick > Right that is the idea. > > on 11/3/03 13:24, Ben Johansen at [EMAIL PROTECTED] wrote: > > > Hey, I could have miss something myself. Monday factor > > > > What I under stand is this > > > > 1 domain name branching too many Web Sites > > > > |- Site 1 > > www.domain.com - > > |- Site 2 > > |- Site 3 > > > > > > Ben Johansen - http://www.pcforge.com > > Authorized Witango & MDaemon Reseller > > Available for Witango Developement > > > > > > -----Original Message----- > > From: Wolf, Gene [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 03, 2003 10:19 AM > > To: '[EMAIL PROTECTED]' > > Subject: RE: Witango-Talk: Looking for thoughts > > > > I may be missing something here but on my server I set up many accounts > > all > > coming in to the same IP address. For example, many of my clients go to > > 205.232.46.15 via their own domain name. For example, > > www.Interactive-Websites.com and www.OldCrackersHome.com both go to the > > exact same IP address, but are sent to different directories by IIS. In > > IIS > > The header is looked at and sent to the specific directory responsible > > for > > that site. If, in that directory there sat a .taf file recording the > > fact > > that someone entered and kicked off a site specific to that client, > > wouldn't > > that accomplish what you're trying to do? > > > > Then again, Maybe I'm misunderstand the whole thing. *laughs* > > > > Sincerely, > > Gene Wolf > > > > -----Original Message----- > > From: Ben Johansen [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 03, 2003 1:14 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Witango-Talk: Looking for thoughts > > > > > > I see a big problem with this, because DNS take a domain name and link > > it to one IP address; hence there is no way to determine which context > > the end user is looking at domain. > > > > The sub-domain option like Rick suggested is the only way I can see the > > domain being visible for all who want to be associated with it. > > Abc.domain.com, def.domain.com > > > > Or you will have to have a main page with links to all who are > > associated with that domain > > > > Ben Johansen - http://www.pcforge.com > > Authorized Witango & MDaemon Reseller > > Available for Witango Developement > > > > > > -----Original Message----- > > From: Dan Stein [mailto:[EMAIL PROTECTED] > > Sent: Monday, November 03, 2003 9:43 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Witango-Talk: Looking for thoughts > > > > I prefer to have the domains point as you do but in the case the deal is > > the > > client owns a much wanted domain that multiple companies want as their > > own. > > Rather than sell it to one he wants to serve all of them in the way > > described. > > > > on 11/3/03 11:47, Robert Shubert at [EMAIL PROTECTED] wrote: > > > >> I prefer to have 6 specific domains that all point to the same > > physical > >> website, then you can logically separate the content by domain, this > >> works well. > >> > >> Otherwise, I would simply take > >> > >> www.site.com/xyz/default_file.taf > >> > >> And have it @ASSIGN user$site = xyz > >> > >> Then META-REFESH www.site.com > >> > >> Then have all your TAFs in www.site.com/ be able to look at the > >> user$site to determine what you present. > >> > >> You will likely have a problem with bookmaking, and will need to deal > >> gracefully with a user at www.site.com without a USERREFERENCE and/or > >> user$site set. > >> > >> Robert > >> > >> -----Original Message----- > >> From: Dan Stein [mailto:[EMAIL PROTECTED] > >> Sent: Monday, November 03, 2003 11:29 AM > >> To: [EMAIL PROTECTED] > >> Subject: Witango-Talk: Looking for thoughts > >> > >> I am drawing up specs for where there will be multiple hosting > > multiple > >> domains from a single backend. > >> > >> In each case we will have multiple companies in each domain but will; > >> want > >> to load specific sites to those companies when users come into the > >> domain. > >> > >> So for instance there may be 6 companies who will all have the domain > >> appearing in the address part of the browser being > >> > >> www.thissite.com > >> > >> But because as user came in through www.thissite.com/xx they will get > > a > >> specific companies site. > >> > >> I want the links to always be hidden so even the www.thissite.com/xxx > >> does > >> not appear in an address bar. > >> > >> The site will in 90% of the cases be flash based and will not have > >> eCommerce > >> functionality. > >> > >> I'm looking for ideas on how to best design this and what the pitfalls > >> and > >> pros and cons might be, > >> > >> Dan > > -- > Dan Stein > Digital Software Solutions > 799 Evergreen Circle > Telford PA 18969 > Land: 215-799-0192 > Mobile: 610-256-2843 > Fax 413-410-9682 > FMP, WiTango, EDI,SQL 2000 > [EMAIL PROTECTED] > www.dss-db.com > > > "When you are born, you cry and those who love you rejoice. And if you > live your life as you should, when you die, you rejoice and those who > love you cry." > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
