If cloaking worked as well as I'd hoped then it would have been a great solution for a number of challenges, but I've played with DNS and routing, cloaking, various redirections and a lot of different stuff like server plugins and it usually takes a number of technologies put together to get the ideal solution.

Dan, would find that there are server plugins which can assist him with this sort of thing, but their features tend to be platform specific. Welcome is a great tool for Webstar and other MAc servers, but there are similar tools which offer URL parsing on both Linux and Windows that he could also use in conjunction with the Witango solution, previously discussed, that would get him across the line.


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


--
Garth Penglase
Broadband Media
http://bbmedia.com.au
ph: 0500 527 000
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf

Reply via email to