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 andcatch any request before the server or other plugins can get them. It is afilter 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 anyoneelse 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 becauseit does not know that something has changed its request inbetween.To do this, you just need to create a Rule in Welcome. A rule isa modification setup that matches something and in case of a matchcan a) change the request, b) redirect the request or c) create ausername/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_subfolderRedirect: not checkedExplanation:The * are wildcards (or jokers if you like) that match any text. I usethem in the path part to create a contains matching. The first * willmatch any text before product_folder and the second any text after it. means a match at the (P)ath field -> This rule will only executeif there was a match in the Path field of the rule.Then, if this rule executes, it will change the actual path to the valueof the Path Result: field. Here, will stand for the matched stringof 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 importantwhere the request comes from. All requests that contain product_folderwill be changed before the server see them. As this only affects theserver, the browser will never see the final request. Exception: Ifyou use a plugin/cgi that will grab the final request (including yourprivate path) and builts a redirect out of it and sends it as a redirectrequest back to the browser, then the browser WILL display the modifiedurl. 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 differentlocations, or they are modified as well (because the browser still thinksit 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 executesaround 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:
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 andcatch any request before the server or other plugins can get them. It is afilter 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 anyoneelse 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 becauseit does not know that something has changed its request inbetween.To do this, you just need to create a Rule in Welcome. A rule isa modification setup that matches something and in case of a matchcan a) change the request, b) redirect the request or c) create ausername/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_subfolderRedirect: not checkedExplanation:The * are wildcards (or jokers if you like) that match any text. I usethem in the path part to create a contains matching. The first * willmatch any text before product_folder and the second any text after it. means a match at the (P)ath field -> This rule will only executeif there was a match in the Path field of the rule.Then, if this rule executes, it will change the actual path to the valueof the Path Result: field. Here, will stand for the matched stringof 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 importantwhere the request comes from. All requests that contain product_folderwill be changed before the server see them. As this only affects theserver, the browser will never see the final request. Exception: Ifyou use a plugin/cgi that will grab the final request (including yourprivate path) and builts a redirect out of it and sends it as a redirectrequest back to the browser, then the browser WILL display the modifiedurl. 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 differentlocations, or they are modified as well (because the browser still thinksit 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 executesaround 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)