Robert,
It's not about security and only partial about "pretty" url's. The
thing is that I am building a meta site which will host a bunch of
sites that other companies can design. Since this will be a portal,
I provide basic functions like login, basket, search etc as components
which then will be used in predefined templates that I create.
As a result, a single T5 app will be used to host several sites - all
distinguished by host name. And inside each site, I have a mixture of
"static" (better: non-db based content like a shopping cart page) and
"dynamic" pages.
Those dynamic pages are not completely free. They are based on html
snippets and a template name and I use the template matching that name
and fill in the snippets from the db - and those snippets again can
contain references to images, css and so.
It's probably easiest show by example:
Customer A has a site SITE-A. I have defined template X, Y and Z. The
customer uploads a page '/test.html' onto an ftp account and a script
fetches:
- the name of the template to use. Let's say X.
- the html of three div's with ids set to i.e. 'left', 'middle', 'right'
- the html in the left column has an <img src="/foo.gif">
What happens here is that after that, my app makes it possible to
call
http://www.SITE-A.com/dynamic/test.html
which will trigger a tapestry page Dynamic with context '/test.html'.
That page (could also be a service but I found a page sufficient) then
uses a Layout component pattern in a dynamic way to use template X.
In template X, there are three components with ref-ids 'left', 'middle'
and 'right'. They will fetch and output the html from the database. The
browser will call '/foo.gif' as a result which will also be fetched
from the database via a tapestry service.
Also, the template X contains some 'internal' graphics. And here, the
problem exists. Unlike the content that comes from the database and
which is fetched with the hostname as a key, the assets inside the
template (i.e. a page header gif) are not separated by hostname. So
I would need to use /site-a/header.gif and /site-b/header.gif in two
templates for site-a and site-b.
I don't want that. Especially since I want to reuse the template by
copying it when a new site is to be added. All I want is to have the
gif in
/myassets/site-a/header.gif
/myassets/site-b/header.gif
in my tapestry project and call it in the code without a notion of the
site it is used at. Same goes for the browser URL. There I don't want
the site notion:
http://www.site-a.com/header.gif
Repeating the site inside the path would be not so nice:
http://www.longsitenamehere.com/longsitenamehere/header.gif
First, it's quite ugly and second, it will create confusion if users
start to abuse other sites content.
Sorry for the long post but I felt that I had to go into detail to
show why I want what I want.
/Andreas Pardeike
PS: Please note that basically everything is already implemented except
for the host separation of my own assets...
PS2: I am thinking of switching the url scheme for 'static' and
'dynamic' pages so the customer pages have the same paths as the
files they upload (all static pages will then have defined subfolder
prefixed). That requires some changes but will still leave me with the
same problem regarding my tapestry assets.
On 28 mar 2008, at 19.32, Robert Zeigler wrote:
Question: is the crux of the matter "pretty" urls, or is the cruz of
the matter security?
If the crux is pretty urls, then we should think about this some
more... trying to map a single url onto multiple resources, and
cache all of those resources seems pretty tricky.
If, on the other hand, you just need to make sure that "site_a"
users don't have access to site_b's assets, then maybe this isn't
the best approach?
For instance, you could use a dispatcher to verify that the user in
question has access to the asset in question.
For example, you could use the AssetProtectionDispatcher* that I
wrote awhile back, and contribute your own AssetPathAuthorizer which
looks at the asset path, and the current user, and determines if the
user has access to the asset.
Then you're not beating your head over trying to map a single url to
multiple assets, and you're using the built-in caching, and site b's
users aren't peaking at site a's assets.
If you also want pretty urls to boot... I'll have to mull over it a
bit when I have a bit more time.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
