Re: Hiding URL ?

This WebDNA talk-list message is from

1998


It keeps the original formatting.
numero = 16928
interpreted = N
texte = Sven U. Grenander wrote: >>>So is there any way that anyone can think of that would allow the hiding >>>of the location that a link really points to (other than using aliases) ? >... >>>would be served, not the one cached at the trunk line. IOW, the alias >>>resolution is done at the Finder level, not under the control of FireSite.>Andreas Pardeike at pardeike@digitalfarmers.com wrote on 4/6/1998 0:52: >>You could use the Welcome Plugin (http://welcome.digitalfarmers.com) to >>modify the path even before FireSite sees it. This feature is called >>Dynamic URL manipulation and redirecton.>The price is definitely right. >I _think_ you are saying that I could specify that a URL which contains >for example: > > .../product_folder/... > >(where the ... are additional path specifiers) could be remapped on the >fly, by the Welcome Plugin, to actually execute as for example: > > .../Actual_Folder/and_subfolder/... > >where the product_folder is replaced by Actual_Folder/and_subfolder. >Or something along those lines. > >If that is a fair interpretation: Would the Actual_Folder/and_subfolder >not be visible to the user or be copyable by doing a copy this link >location ? Would the FireSite software see the >Actual_Folder/and_subfolder before passing it on for processing by >WebStar ?Sven,Welcome , is designed to sit around and catch any request before the server or other plugins can get them. It is a filter plugin and if you rename it so it comes before any other filter plugin (like FireSite) it has the chance to modify the incoming request before anyone else will even see the original request.Here is the scheme:1) Browser (Location: field) = www.bzz.com/xxx/product_folder/yyy2) Request send to the server = GET /xxx/product_folder/yy Host: www.bzz.com User-Agent: a browser3) Welcome changes it to = GET /xxx/Actual_Folder/and_subfolder/yy Host: www.bzz.com User-Agent: a browser4) Server & other plugins get this and return the resulting page.5) Browser is still displaying www.bzz.com/xxx/product_folder/yyy because it does not know that something has changed its request inbetween.To do this, you just need to create a Rule in Welcome. A rule is a modification setup that matches something and in case of a match can a) change the request, b) redirect the request or c) create a username/password dialog in the browser.Here is a rule that will do the scheme above:Rule my product hiddingPath: *product_folder* Condition: Path Result: Actual_Folder/and_subfolder Redirect: not checkedExplanation:The * are wildcards (or jokers if you like) that match any text. I use them in the path part to create a contains matching. The first * will match any text before product_folder and the second any text after it. means a match at the (P)ath field -> This rule will only execute if there was a match in the Path field of the rule. Then, if this rule executes, it will change the actual path to the value of the Path Result: field. Here, will stand for the matched string of the first * and stands for the second *. In the example above, these values are: = true = /xxx/ = /yyyso the Path Result is: /xxx/ + Actual_Folder/and_subfolder + /yyyRedirect: not checked means, that Welcome does not create a redirect (which WILL show the new path in the Location field of the browser) but will simply change the HTTP header.>If the user just sees the .../product_folder/... URL, won't the user >still get to .../Actual_Folder/and_subfolder/... if they create a URL >which looks like .../product_folder/... or can Welcome detect that is a >link from an external page and thus shouldn't be processed ?If you look at the scheme above, you might see that it is not important where the request comes from. All requests that contain product_folder will be changed before the server see them. As this only affects the server, the browser will never see the final request. Exception: If you use a plugin/cgi that will grab the final request (including your private path) and builts a redirect out of it and sends it as a redirect request back to the browser, then the browser WILL display the modified url. But this should not happen if you simply point/xxx/product_folder/somepage.htmlto/xxx/Actual_Folder/and_subfolder/somepage.htmlAll links and images from that page are either to totally different locations, or they are modified as well (because the browser still thinks it is requesting /xxx/product_folder/somepage.html>Since all of the above is being done to enhance serving performance while >using WebCat/WebMerchant; what's the performance hit that Welcome would >introduce ? Are there any stability problems to be considered ? Do you >know of a place where Welcome is used with Web*, WebCat, WebMerchant and >Firesite ? Just one word: NO performance hit for 5 - 15 rules. Each rule executes around 0.0001 seconds, simply forget about them.>Sorry to be so verbose about all of this. It seems like you might have >the answer that's needed, but I sure don't understand it all quite yet >:-) I could say I'm sooo confused!You know: There are only dumb answer, but never dumb questions...May the support be with youAndreas Pardeike - NEW MAIL ADDRESS: pardeike@digitalfarmers.com ----------------------------------------------------------------- Pardeikes Welcome Plugin - Virtual Hosting and Dynamic URL Manipulations with Search/Replace Associated Messages, from the most recent to the oldest:

    
  1. Re: Hiding URL ? (Andreas Pardeike 1998)
  2. Re: Hiding URL ? (Sven U. Grenander 1998)
  3. Re: Hiding URL ? (Andreas Pardeike 1998)
  4. Hiding URL ? (Sven U. Grenander 1998)
Sven U. Grenander wrote: >>>So is there any way that anyone can think of that would allow the hiding >>>of the location that a link really points to (other than using aliases) ? >... >>>would be served, not the one cached at the trunk line. IOW, the alias >>>resolution is done at the Finder level, not under the control of FireSite.>Andreas Pardeike at pardeike@digitalfarmers.com wrote on 4/6/1998 0:52: >>You could use the Welcome Plugin (http://welcome.digitalfarmers.com) to >>modify the path even before FireSite sees it. This feature is called >>Dynamic URL manipulation and redirecton.>The price is definitely right. >I _think_ you are saying that I could specify that a URL which contains >for example: > > .../product_folder/... > >(where the ... are additional path specifiers) could be remapped on the >fly, by the Welcome Plugin, to actually execute as for example: > > .../Actual_Folder/and_subfolder/... > >where the product_folder is replaced by Actual_Folder/and_subfolder. >Or something along those lines. > >If that is a fair interpretation: Would the Actual_Folder/and_subfolder >not be visible to the user or be copyable by doing a copy this link >location ? Would the FireSite software see the >Actual_Folder/and_subfolder before passing it on for processing by >WebStar ?Sven,Welcome , is designed to sit around and catch any request before the server or other plugins can get them. It is a filter plugin and if you rename it so it comes before any other filter plugin (like FireSite) it has the chance to modify the incoming request before anyone else will even see the original request.Here is the scheme:1) Browser (Location: field) = www.bzz.com/xxx/product_folder/yyy2) Request send to the server = GET /xxx/product_folder/yy Host: www.bzz.com User-Agent: a browser3) Welcome changes it to = GET /xxx/Actual_Folder/and_subfolder/yy Host: www.bzz.com User-Agent: a browser4) Server & other plugins get this and return the resulting page.5) Browser is still displaying www.bzz.com/xxx/product_folder/yyy because it does not know that something has changed its request inbetween.To do this, you just need to create a Rule in Welcome. A rule is a modification setup that matches something and in case of a match can a) change the request, b) redirect the request or c) create a username/password dialog in the browser.Here is a rule that will do the scheme above:Rule my product hiddingPath: *product_folder* Condition: Path Result: Actual_Folder/and_subfolder Redirect: not checkedExplanation:The * are wildcards (or jokers if you like) that match any text. I use them in the path part to create a contains matching. The first * will match any text before product_folder and the second any text after it. means a match at the (P)ath field -> This rule will only execute if there was a match in the Path field of the rule. Then, if this rule executes, it will change the actual path to the value of the Path Result: field. Here, will stand for the matched string of the first * and stands for the second *. In the example above, these values are: = true = /xxx/ = /yyyso the Path Result is: /xxx/ + Actual_Folder/and_subfolder + /yyyRedirect: not checked means, that Welcome does not create a redirect (which WILL show the new path in the Location field of the browser) but will simply change the HTTP header.>If the user just sees the .../product_folder/... URL, won't the user >still get to .../Actual_Folder/and_subfolder/... if they create a URL >which looks like .../product_folder/... or can Welcome detect that is a >link from an external page and thus shouldn't be processed ?If you look at the scheme above, you might see that it is not important where the request comes from. All requests that contain product_folder will be changed before the server see them. As this only affects the server, the browser will never see the final request. Exception: If you use a plugin/cgi that will grab the final request (including your private path) and builts a redirect out of it and sends it as a redirect request back to the browser, then the browser WILL display the modified url. But this should not happen if you simply point/xxx/product_folder/somepage.htmlto/xxx/Actual_Folder/and_subfolder/somepage.htmlAll links and images from that page are either to totally different locations, or they are modified as well (because the browser still thinks it is requesting /xxx/product_folder/somepage.html>Since all of the above is being done to enhance serving performance while >using WebCat/WebMerchant; what's the performance hit that Welcome would >introduce ? Are there any stability problems to be considered ? Do you >know of a place where Welcome is used with Web*, WebCat, WebMerchant and >Firesite ? Just one word: NO performance hit for 5 - 15 rules. Each rule executes around 0.0001 seconds, simply forget about them.>Sorry to be so verbose about all of this. It seems like you might have >the answer that's needed, but I sure don't understand it all quite yet >:-) I could say I'm sooo confused!You know: There are only dumb answer, but never dumb questions...May the support be with youAndreas Pardeike - NEW MAIL ADDRESS: pardeike@digitalfarmers.com ----------------------------------------------------------------- Pardeikes Welcome Plugin - Virtual Hosting and Dynamic URL Manipulations with Search/Replace Andreas Pardeike

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

random images (1997) a search based on ^(contains) (1998) Displays by Categories (2000) [SMSI] WebDNA is too good to go away! (2006) test (2004) quantity minimum problem (1997) Include (2000) WebCatalog on G3 Macs? (1997) Reminder for beta testers (2000) [WebDNA] Using WebDNA with MAMP (2010) [WriteFile] problems (1997) The Form authentication trick (2000) converted seed value? (1998) Weird problems with [SHOWIF]s (1997) functions... (2005) Problems with SELECT MULTIPLE (1999) [Announce]: Web server security and password protection (1997) more ! testing (1997) Re:no [search] with NT (1997) Garbage files created (2000)