You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2007/04/17 11:00:52 UTC
[1.4] /{pub-id}/{module}/... URLS interfering with areas
Hi Lenya devs,
ATM it is allowed to use URLs like
/{pub-id}/{module}/foo.xml
This interferes with areas. Specifically, the UuidToUrlTransformer
rewrites
/default/resource/icons/...
to
/default/authoring/icons/...
because "resource" is not the current area.
That's why the icon on resource pages doesn't appear.
Another problem is that it doesn't work with proxies out of
the box, since the area's URL space is not self-contained.
We could change this to
/{pub}/{area}/{module}
but this would imply a reserved URL space for each module
which can't be used for content.
Or:
/{pub}/{area}/modules/{module}/...
/{pub}/{area}/lenya-modules/{module}/...
The former is less verbose, but more likely to cause URL clashes.
The latter is probably quite safe.
WDYT?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Andreas Hartmann wrote:
> Sounds reasonable. IIUC, that would mean
>
> /{pub}/{area}/modules/{module}/...
>
> Should we remove support for the following URL syntax?
>
> /{pub}/modules/{module}/...
>
> IMO yes - when we get rid the area-in-url concept, everything goes
> just one level up.
i'd rather keep this. modules might do stuff differently depending on
the area (which would have to be changed when areas go away), but they
might also do stuff regardless of area, and that does not need to be
changed. for instance, the profiling module uses such URIs, as does
tinymce iirc, but i'd need to check that.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Joern Nettingsmeier schrieb:
>>> iirc there was consensus to get rid of the area concept in future
>>> developments, so we should not add more area-handling code now if
>>> possible...
>>
>> Agreed. So maybe we should add a small workaround to the
>> uuid2url transformer.
>>
>>> anyways, why does the transformer have to rewrite what it thinks is the
>>> "area" part of the URL at all?
>>
>> /*
>> * This is legacy code. It rewrites links to
>> * non-document images (in resources/shared). These
>> * images shouldn't be referenced in documents since
>> * this violates the separation between content and
>> * layout.
>> */
>>
>> The URLs have to be rewritten, e.g., when publishing a document.
>> We could just match for "authoring" here, that should do for the
>> moment.
>
> i see. yes, a commented hack that's local to the rewriter is probably best.
Done.
>>>>> /{pub}/{area}/modules/{module}/...
>>>>> /{pub}/{area}/lenya-modules/{module}/...
>>>>>
>>>>> The former is less verbose, but more likely to cause URL clashes. The
>>>>> latter is probably quite safe.
>>>>>
>>>>> OTOH, some people might not want external URLs to contain the name
>>>>> of the CMS. Should we make this configurable?
>>> i'd very much prefer convention over configuration in such matters.
>>> and for the reason you stated, i prefer "modules".
>>
>> Is this sufficient re. forward compatibility, or should we use
>> "lenya/modules", in case there are other CMS-related URL spaces
>> to come?
>
> good point.
> but i think in the future we should keep out of the uri space as far as
> possible. and everything should be a module. so reserving "module" is
> sufficient imho, and it imposes some discipline on us wrt uri space :)
Sounds reasonable. IIUC, that would mean
/{pub}/{area}/modules/{module}/...
Should we remove support for the following URL syntax?
/{pub}/modules/{module}/...
IMO yes - when we get rid the area-in-url concept, everything goes
just one level up.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier schrieb:
>> iirc there was consensus to get rid of the area concept in future
>> developments, so we should not add more area-handling code now if
>> possible...
>
> Agreed. So maybe we should add a small workaround to the
> uuid2url transformer.
>
>> anyways, why does the transformer have to rewrite what it thinks is the
>> "area" part of the URL at all?
>
> /*
> * This is legacy code. It rewrites links to
> * non-document images (in resources/shared). These
> * images shouldn't be referenced in documents since
> * this violates the separation between content and
> * layout.
> */
>
> The URLs have to be rewritten, e.g., when publishing a document.
> We could just match for "authoring" here, that should do for the
> moment.
i see. yes, a commented hack that's local to the rewriter is probably best.
>>>> /{pub}/{area}/modules/{module}/...
>>>> /{pub}/{area}/lenya-modules/{module}/...
>>>>
>>>> The former is less verbose, but more likely to cause URL clashes. The
>>>> latter is probably quite safe.
>>>>
>>>> OTOH, some people might not want external URLs to contain the name
>>>> of the CMS. Should we make this configurable?
>> i'd very much prefer convention over configuration in such matters.
>> and for the reason you stated, i prefer "modules".
>
> Is this sufficient re. forward compatibility, or should we use
> "lenya/modules", in case there are other CMS-related URL spaces
> to come?
good point.
but i think in the future we should keep out of the uri space as far as
possible. and everything should be a module. so reserving "module" is
sufficient imho, and it imposes some discipline on us wrt uri space :)
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Andreas Hartmann schrieb:
>>> Hi Lenya devs,
>>>
>>> ATM it is allowed to use URLs like
>>>
>>> /{pub-id}/{module}/foo.xml This interferes with areas.
>>> Specifically, the UuidToUrlTransformer rewrites
>>>
>>> /default/resource/icons/...
>>>
>>> to
>>>
>>> /default/authoring/icons/...
>>>
>>> because "resource" is not the current area. That's why the icon on
>>> resource pages doesn't appear.
>
> iirc there was consensus to get rid of the area concept in future
> developments, so we should not add more area-handling code now if
> possible...
Agreed. So maybe we should add a small workaround to the
uuid2url transformer.
> anyways, why does the transformer have to rewrite what it thinks is the
> "area" part of the URL at all?
/*
* This is legacy code. It rewrites links to
* non-document images (in resources/shared). These
* images shouldn't be referenced in documents since
* this violates the separation between content and
* layout.
*/
The URLs have to be rewritten, e.g., when publishing a document.
We could just match for "authoring" here, that should do for the
moment.
>>> Another problem is that it doesn't work with proxies out of the
>>> box, since the area's URL space is not self-contained.
>>>
>>>
>>> We could change this to
>>>
>>> /{pub}/{area}/{module}
>>>
>>> but this would imply a reserved URL space for each module which
>>> can't be used for content.
>
> -1, since there is no way for users to know which module names are
> reserved.
Agreed.
>>> Or:
>>>
>>> /{pub}/{area}/modules/{module}/...
>>> /{pub}/{area}/lenya-modules/{module}/...
>>>
>>> The former is less verbose, but more likely to cause URL clashes. The
>>> latter is probably quite safe.
>>>
>>> OTOH, some people might not want external URLs to contain the name
>>> of the CMS. Should we make this configurable?
>
> i'd very much prefer convention over configuration in such matters.
> and for the reason you stated, i prefer "modules".
Is this sufficient re. forward compatibility, or should we use
"lenya/modules", in case there are other CMS-related URL spaces
to come?
> although it would
> still be distinct enough that an attacker could easily google for lenya
> sites to exploit lenya security holes... but as long as we have areas,
> we're wide open to such attacks anyways, since most sites will have
> "live" in their uris somewhere unless they are proxying.
>
>
>> We could use a configurable prefix (preset to "lenya"):
>>
>> /{pub}/{area}/{lenya-prefix}/modules
>>
>> For instance
>>
>> /default/authoring/lenya/modules /yourpub/authoring/cms/modules
>
> -1
> this thing will be a world of pain to support...
Yes, that's true.
Thanks for your comments!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
Andreas Hartmann wrote:
> Andreas Hartmann schrieb:
>> Hi Lenya devs,
>>
>> ATM it is allowed to use URLs like
>>
>> /{pub-id}/{module}/foo.xml This interferes with areas.
>> Specifically, the UuidToUrlTransformer rewrites
>>
>> /default/resource/icons/...
>>
>> to
>>
>> /default/authoring/icons/...
>>
>> because "resource" is not the current area. That's why the icon on
>> resource pages doesn't appear.
iirc there was consensus to get rid of the area concept in future
developments, so we should not add more area-handling code now if
possible...
anyways, why does the transformer have to rewrite what it thinks is the
"area" part of the URL at all?
>> Another problem is that it doesn't work with proxies out of the
>> box, since the area's URL space is not self-contained.
>>
>>
>> We could change this to
>>
>> /{pub}/{area}/{module}
>>
>> but this would imply a reserved URL space for each module which
>> can't be used for content.
-1, since there is no way for users to know which module names are reserved.
>> Or:
>>
>> /{pub}/{area}/modules/{module}/...
>> /{pub}/{area}/lenya-modules/{module}/...
>>
>> The former is less verbose, but more likely to cause URL clashes.
>> The latter is probably quite safe.
>>
>> OTOH, some people might not want external URLs to contain the name
>> of the CMS. Should we make this configurable?
i'd very much prefer convention over configuration in such matters.
and for the reason you stated, i prefer "modules". although it would
still be distinct enough that an attacker could easily google for lenya
sites to exploit lenya security holes... but as long as we have areas,
we're wide open to such attacks anyways, since most sites will have
"live" in their uris somewhere unless they are proxying.
> We could use a configurable prefix (preset to "lenya"):
>
> /{pub}/{area}/{lenya-prefix}/modules
>
> For instance
>
> /default/authoring/lenya/modules /yourpub/authoring/cms/modules
-1
this thing will be a world of pain to support...
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Andreas Hartmann schrieb:
>> Hi Lenya devs,
>>
>> ATM it is allowed to use URLs like
>>
>> /{pub-id}/{module}/foo.xml
>
> [...]
>
>> We could change this to
>>
>> /{pub}/{area}/{module}
>>
>> but this would imply a reserved URL space for each module
>> which can't be used for content.
>>
>> Or:
>>
>> /{pub}/{area}/modules/{module}/...
>> /{pub}/{area}/lenya-modules/{module}/...
>>
>> The former is less verbose, but more likely to cause URL clashes.
>> The latter is probably quite safe.
>
> OTOH, some people might not want external URLs to contain the
> name of the CMS. Should we make this configurable?
>
> We could use a configurable prefix (preset to "lenya"):
>
> /{pub}/{area}/{lenya-prefix}/modules
>
> For instance
>
> /default/authoring/lenya/modules
> /yourpub/authoring/cms/modules
I submitted a patch which uses a global sitemap variable:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42140
It seems to work well.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] /{pub-id}/{module}/... URLS interfering with areas
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> ATM it is allowed to use URLs like
>
> /{pub-id}/{module}/foo.xml
[...]
> We could change this to
>
> /{pub}/{area}/{module}
>
> but this would imply a reserved URL space for each module
> which can't be used for content.
>
> Or:
>
> /{pub}/{area}/modules/{module}/...
> /{pub}/{area}/lenya-modules/{module}/...
>
> The former is less verbose, but more likely to cause URL clashes.
> The latter is probably quite safe.
OTOH, some people might not want external URLs to contain the
name of the CMS. Should we make this configurable?
We could use a configurable prefix (preset to "lenya"):
/{pub}/{area}/{lenya-prefix}/modules
For instance
/default/authoring/lenya/modules
/yourpub/authoring/cms/modules
WDYT?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org