Might very well be you are right Garth. Haven't tried out the functionality of it myself, so I can't say I have those "hands on" experiences of how it works and what new problems rise in practise. As a consept though it's compelling since you don't have to handle it and get the additional possibility to use the ip ports.
Jan > -----Original Message----- > From: Garth Penglase [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 04, 2003 13:23 > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: Looking for thoughts > > > cloaking or web alias as you've called it, isn't universally > supported - it will 'break' in a fair number of browsers and is > supported in different levels between different versions. Also, it > involves placing a frameset between the website and the browser which > strongly interferes with robot/spider indexing - there can also be > problems with bookmarking on cloaked sites due to the 'hidden' > frameset. > > can be useful for certain sites but I wouldn't recommend it for what > Dan is trying to do for his client. > > > >Hi Dan, > > > >I'm not sure I understood what you exactly are trying to > achieve. But if you > >want to direct customers to different urls the urls still > showing up as one > >and the same (or maybe having multiple urls) I think you should also look > >into something the ISP:s call "Web Forwarding" and "Web Alias" > (depending on > >ISP). > > > >It's a feature they have built into their dsn services. They thereby in > >effect hide the real url address providing the user with the one > you choose. > >And (this is the important one) it can be extended so that all urls > >underneath only show to the user as the original domain url. > This seems also > >to be extended to include routing thru some specific IP port > etc. making it > >possible to use non-standard IP ports without showing it to the > customer so > >you don't have to designate a separate specific IP address for each and > >every customer. > > > >Example: > > > >Main url: www.mysite.com (what you want to show to the customer) > > > >www.mysite.com/site1/default.taf will still show up as only > www.mysite.com > >on the browser of the user > > > >www.mysite.com/site2/sometaf.taf will also show up as only > www.mysite.com on > >the browser of the user > > > >Here is one link to one company providing these services: > > > >http://www.constanttime.com/store/aboutwebforwarding.jsp > > > >More can be found with searching on at least "web forwarding" and "web > >alias". > > > >Jan > > > >> -----Original Message----- > >> From: Dan Stein [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, November 04, 2003 05:09 > >> To: [EMAIL PROTECTED] > >> Subject: Re: Witango-Talk: Looking for thoughts > >> > >> > >> The way I am starting to see this is a little bit different now. > >> Maybe since > >> at least in the case of one of these Domains the companies interested > >> already have a web site or will want to have one if they > don't and this > >> domain like several of the others would be a special aspect of their > >> company. Therefore we could drive them to the site in a known way > >> because we > >> would control the link from there company site. > >> > >> So for example the company is: shoes.com and they want to > drive people to > >> their special section spaceboots.com > >> > >> We could have multiple people going to spacceboots.com from > the button on > >> this site that is part of a form that can submit the rest of the > >> info hidden > >> so the link itself is not visible. > >> > >> Then any of the several suggestions for pushing them to the "sub > >> site" would > >> work. > >> > >> Does this begin to make some of the issues raised easier to > handle? Sounds > >> like I'm on the right track at least. > >> > >> Dan > >> on 11/3/03 15:35, Jim Kass at [EMAIL PROTECTED] wrote: > >> > >> > 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 > >> > > >> > >> -- > >> 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 > > > -- > Garth Penglase > Broadband Media > http://bbmedia.com.au > ph: 0500 527 000 > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
