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

Reply via email to