11 Apr
2016
11 Apr
'16
3:47 p.m.
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent(a)massol.net> wrote:
> On 11 Apr 2016, at 15:07, Vincent Massol <vincent(a)massol.net> wrote:
>
>>
>> On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
>>
>> On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>
>>>> On 08 Apr 2016, at 10:00, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
>>>>
>>>> I'm hesitating, the thing is that what webjars really want to know
in
>>>> practice is the namespace since that what it will provide to
>>>> ClassLoaderManager so maybe the best is to indicate the namespace
>>>> instead of the wiki in the URL. It means that webjar service can
>>>> support both wiki and users right now and any future namespaces
>>>> (document, space, etc).
>>>
>>> Don’t you think that we need the wiki in order to validate permissions:
>>>
>>> "// 2) so that we can set the current user in the Context and at the
same time verify that the current user has
>>> // View Rights on this wiki"
>>>
>>> At
https://github.com/xwiki/xwiki-platform/blob/4f2f6fa823d3d222851f7001237b0b…
>>>
>>
>>> Of course we could generalize and say that we pass a serialized entity
reference (or resource reference) instead of the wikiId. Note that we would also need to
pass the entity type (or resource reference type), so it would need to be something like
“/wiki:wikiId/…”.
>>
>> "wiki:wikiId" is a the namespace for wiki with id "wikiId".
>>
>>>
>>> Maybe this is too much for now. It’s more work and I’m not sure about the use
cases...
>>
>> It's not really that simple IMO. You will have to change the URL
>> format and find an alternative that can work along with the old format
>> to not break it. The thing is you could have an extension in any
>> namespace, the standard UI just give you wikis choice but it's not the
>> case for classloadersmanager/extensionmanager API. As for the user
>> case, I don't think installing an extension in a space would be so
>> weird compare to installing an extension in a wiki. It does not really
>> make much difference for Extension Manager.
>
> However we still need to have the wikiId somewhere in the URL because we'll need
to set the current wiki (at least to validate permissions).
>
> So what you’re saying (I think) is that we need 2 more info in the URL: wikiId +
namespace, right?
No I'm not saying that. You don't have wikis on one side and
namespaces on another side being completely different things. Wikis
have namespaces to represent them, you install an extension on a
namespace for example (and then XAR extension handler understand from
"wiki:toto" namespace that it will have to import pages on wiki
"toto").
How to deal with permission depend on the kind of namespace. You just
need security handlers to which you ask for READ right on namespace
"wiki:toto" and will behind the scene translate it to a READ right on
entity WIKI with id "toto" and return you the result (later we'll
probably have a more generic entity handler dealing with "wiki:",
"space:", "document:", etc.), the one associated to user will check
that current user is the target user (and probably also allow admin of
the target user wiki and farm to access it too), etc.
BTW, AFAICS , the ContextNamespaceURLClassLoader class only deals with a wiki namespace
ATM. Are you saying that we should modify this to handle other use cases? Or that
WebJarsResourceReferenceHandler should not use the current thread CL?
No, I'm saying that you forget about ContextNamespaceURLClassLoader
completely in the webjars use case. Instead of
WebJarsResourceReferenceHandler it will use
ClassLoaderManager#getURLClassLoader with the namespace found in the
URL. In other words in WebJarsResourceReferenceHandler you replace the
current
Thread.currentThread().getContextClassLoader()
with
this.classlLoaderManager.getURLClassLoader(namespace)
ContextNamespaceURLClassLoader job is not to "deals with a wiki
namespace", it deals with context. What it currently support in the
context is pretty much implementation details. In the future we will
most probably add in it support for spaces, documents, etc. and it
won't change any API or what this component is about.
So the URL:
/<context>/webjars/wiki:mywiki/application-ckeditor-webjar/1.4/ckeditor.js
you start searching for resource
"application-ckeditor-webjar/1.4/ckeditor.js" in wiki "mywiki" and
then fallback on farm classloader and then container classloader
because that's its parents.
Thanks
-Vincent
--
Thomas Mortagne
So something like:
/<context>/webjars/mywiki/wiki:mywiki/application-ckeditor-webjar/1.4/ckeditor.js
Generic format:
/<context>/webjars/<wikiId>/<namespace where to find
resource>/<path/to/resource>
Unless the namespace is absolute but I don’t know what’s the format right now. Does a
space namespace also specified the wiki?
Thanks
-Vincent
>> Thanks
>> -Vincent
>>
>>
>>> On Fri, Apr 8, 2016 at 9:06 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>>>> Hi devs,
>>>>
>>>> In order to fix http://jira.xwiki.org/browse/XWIKI-13276, I’m proposing:
>>>>
>>>> * Use Case 1: No wiki specified:
>>>>
>>>>
$services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar',
'ckeditor.js’)
>>>>
>>>> would generate:
>>>>
>>>>
/<context>/webjars/<currentWikiId>/application-ckeditor-webjar/1.4/ckeditor.js
>>>>
>>>> * Use Case 2: Wiki specified:
>>>>
>>>>
$services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar',
'ckeditor.js', {'wiki': 'mywiki’)
>>>>
>>>> would generate
>>>>
>>>>
/<context>/webjars/mywiki/application-ckeditor-webjar/1.4/ckeditor.js
>>>>
>>>> Generic format:
>>>>
>>>> /<context>/webjars/<wikiId>/path/to/resource
>>>>
>>>> WDYT?
>>>>
>>>> I prefer this over having to deal with domain vs path-based; I also find
it more clear.
>>>>
>>>> Thanks
>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs