pbwebgui-development

[Pbwebgui-development] extras URL

[Leendert B. <lee...@un...>]

I'm currently experimenting with setting up WebGUI to run on two
different http servers. I use an Apache/mod_perl server for the dynamic
content (generating the pages), and thttpd (a forth-generation
Non-blocking I/O server) for serving all static content (uploads and
extras).
I was very pleased with the way WebGUI supports the configuration of the
extras and uploads URL, this makes setting up a config like mine quite
easy.
I encountered a problem though with some of the javascript that is in
the extras directory and is used in functionality such as the HTML
editors. The extras-url must be different from the site-url because it
is served by a different http-server. It's also possible to use the same
url, but on a different port. This results in the HTML-editor javascript
to be served from a different domain than the website in which the edit
form is present. This causes a javascript security exception, so the
editor will NOT work.

To conclude: as long as the default javascripts that come with WebGUI
are approached from the extrasURL that is configured in the config-file,
you can't serve the extras folder from another server.
Solution: seperate the javascript that comes with WebGUI and put them in
a javascript folder that can be configured seperately from the
extras-folder and -url. It won't be a bad idea at all to join all
javascript into one folder, aside from the reasons mentioned before.

JT, what do you say about this?

-leendert

Re: [Pbwebgui-development] extras URL

[Martin K. <ma...@pr...>]

Leendert Bottelberghs wrote:

> To conclude: as long as the default javascripts that come with WebGUI 
> are approached from the extrasURL that is configured in the 
> config-file, you can't serve the extras folder from another server.
> Solution: seperate the javascript that comes with WebGUI and put them 
> in a javascript folder that can be configured seperately from the 
> extras-folder and -url. It won't be a bad idea at all to join all 
> javascript into one folder, aside from the reasons mentioned before.
>
If I understand you correctly, I think using some transparent proxy 
(that redirects all http://my.url.tld/extras/* ) also solves your 
problem. This way the url stays the same but the server serving the 
scripts and collateral is actually another. I think mod_rewrite can also 
do this, but I'm not entirely sure.


> JT, what do you say about this?
>
> -leendert 

Re: [Pbwebgui-development] extras URL

[Flavio C. <lis...@no...>]

Hello

On Fri, Jul 09, 2004 at 03:33:44PM +0200, Martin Kamerbeek wrote:
> If I understand you correctly, I think using some transparent proxy 
> (that redirects all http://my.url.tld/extras/* ) also solves your 
> problem. This way the url stays the same but the server serving the 
> scripts and collateral is actually another. I think mod_rewrite can also 
> do this, but I'm not entirely sure.
mod_rewrite could certainly do this, but only (imho) using the proxy
directive. but then apache has to fetch the url and serve the content to
the client, which imho defeats the purpose of seperate servers...

i'm not even sure if <script lang='javascript'
src='http://somewhere.else/bla.js'> would work and not trigger a
security exception too... 

hope it helps & greets

Flavio

--
http://no-way.org/~fcu/

Mach mit bei der Community-Bibliothek
  - In Zuerich/CH http://zurich.communitybooks.org/
  - Worldwide http://dlpdev.theps.net/ListOfExistingDlpNodes

Re: [Pbwebgui-development] extras URL

[Martin K. <ma...@pr...>]

Flavio Curti wrote:

>Hello
>
>On Fri, Jul 09, 2004 at 03:33:44PM +0200, Martin Kamerbeek wrote:
>  
>
>>If I understand you correctly, I think using some transparent proxy 
>>(that redirects all http://my.url.tld/extras/* ) also solves your 
>>problem. This way the url stays the same but the server serving the 
>>scripts and collateral is actually another. I think mod_rewrite can also 
>>do this, but I'm not entirely sure.
>>    
>>
>mod_rewrite could certainly do this, but only (imho) using the proxy
>directive. but then apache has to fetch the url and serve the content to
>the client, which imho defeats the purpose of seperate servers...
>  
>
I think you can connect through sockets, which is AFAIK pretty fast.

>i'm not even sure if <script lang='javascript'
>src='http://somewhere.else/bla.js'> would work and not trigger a
>security exception too... 
>
>  
>
It would if you use the somewhere.else url, but using a proxy you can 
use the same url as the rest of the site runs on.

Re: [Pbwebgui-development] extras URL

[Dan C. P. <dp...@ml...>]

Leendert,

You could just proxy through the extras folder via a rewrite rule.  Then
apache sits on the frontend with thttpd sitting behind serving the
static stuff.

That may seem pointless at first look because you're using the heavy
apache interpreter as a proxy for the lightweight thttpd (is that a
kernel-level httpd daemon?). However,  as I understand it apache is an
extremely efficient proxy server.

The big efficiency you'll miss using apache as a proxy is the "lingering
socket" problems associated with users on slower connections (the slower
the download, the longer a user ties a heavy mod_perl process up), but
the "negotiate/read/serve" part will be handled mostly by thttpd.

It'd probably make more sense to come at this from the other direction,
though.  Put thttpd in front of your apache/mod_perl process and then
have it handle everything under /extras/ and /uploads/ (though what'll
that do for security?) and proxy everything else through to your
mod_perl process. I assume thttpd supports this kind of setup, otherwise
you can just use a lightweight apache interpreter without mod_perl for
the frontend.  

I've set up a couple systems like this in the past, with a "lightweight"
apache interpreter serving static content in front and a heavier
mod_perl interpreter in back serving mod_perl stuff. It's not hard.

I can help you with the rewrite/proxy stuff if you want. 

-DJCP

On Fri, 2004-07-09 at 09:21, Leendert Bottelberghs wrote:
> I'm currently experimenting with setting up WebGUI to run on two
> different http servers. I use an Apache/mod_perl server for the
> dynamic content (generating the pages), and thttpd (a forth-generation
> Non-blocking I/O server) for serving all static content (uploads and
> extras).
> I was very pleased with the way WebGUI supports the configuration of
> the extras and uploads URL, this makes setting up a config like mine
> quite easy.
> I encountered a problem though with some of the javascript that is in
> the extras directory and is used in functionality such as the HTML
> editors. The extras-url must be different from the site-url because it
> is served by a different http-server. It's also possible to use the
> same url, but on a different port. This results in the HTML-editor
> javascript to be served from a different domain than the website in
> which the edit form is present. This causes a javascript security
> exception, so the editor will NOT work.
> 
> To conclude: as long as the default javascripts that come with WebGUI
> are approached from the extrasURL that is configured in the
> config-file, you can't serve the extras folder from another server.
> Solution: seperate the javascript that comes with WebGUI and put them
> in a javascript folder that can be configured seperately from the
> extras-folder and -url. It won't be a bad idea at all to join all
> javascript into one folder, aside from the reasons mentioned before.
> 
> JT, what do you say about this?
> 
> -leendert
-- 
*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*^*-._.-*

Daniel Collis Puro
CTO and Lead Developer, MassLegalServices.org
Massachusetts Law Reform Institute
99 Chauncy St., Suite 500
Boston, MA 02111
617-357-0019 ext. 342
dp...@ml...
http://www.masslegalservices.org

Re: [Pbwebgui-development] extras URL

[JT S. <jt...@pl...>]

I'm not sure how this solves the security problem. The javascript will still be calling 
a page from a new host, so wouldn't it then still cause a security problem?

I guess what I'm saying is that I don't think this is a WebGUI configuration issue, but 
rather a server config issue. To avoid the security issue I think you need a front end 
proxy that masks the backend servers. So when a request is made for a page that has 
javascript in it, you'd have this:


page req -> proxy (www.me.com) -> webgui (wg.me.com)

js req -> proxy (www.me.com) -> static server (extras.me.com)

With a setup like this it will both boost performance (because the proxy server is 
handling the latent requests) and solve the security issue (because the browser thinks 
everything came from the same source).


On 09 Jul 2004 15:21:42 +0200
  Leendert Bottelberghs <lee...@un...> wrote:
>I'm currently experimenting with setting up WebGUI to run on two
>different http servers. I use an Apache/mod_perl server for the dynamic
>content (generating the pages), and thttpd (a forth-generation
>Non-blocking I/O server) for serving all static content (uploads and
>extras).
>I was very pleased with the way WebGUI supports the configuration of the
>extras and uploads URL, this makes setting up a config like mine quite
>easy.
>I encountered a problem though with some of the javascript that is in
>the extras directory and is used in functionality such as the HTML
>editors. The extras-url must be different from the site-url because it
>is served by a different http-server. It's also possible to use the same
>url, but on a different port. This results in the HTML-editor javascript
>to be served from a different domain than the website in which the edit
>form is present. This causes a javascript security exception, so the
>editor will NOT work.
>
>To conclude: as long as the default javascripts that come with WebGUI
>are approached from the extrasURL that is configured in the config-file,
>you can't serve the extras folder from another server.
>Solution: seperate the javascript that comes with WebGUI and put them in
>a javascript folder that can be configured seperately from the
>extras-folder and -url. It won't be a bad idea at all to join all
>javascript into one folder, aside from the reasons mentioned before.
>
>JT, what do you say about this?
>
>-leendert


JT ~ Plain Black

Create like a god, command like a king, work like a slave.