11 Apr
2016
11 Apr
'16
6 p.m.
On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <vincent(a)massol.net> wrote:
No there is no namespace oriented authorization API right now because
we did not had the need yet but it should not be too complex to
implement.
Why do I need to fallback manually, isn’t that the role of the getResource() method of
the CL returned by this.classlLoaderManager.getURLClassLoader(namespace)? If those are its
parent, then the return CL should have them as parents, no?
The "you" is a leftover, what I described is what append from client
point of you. Of course the classloader is fallbacking on its parents
automatically. Again you just replace the thread classloader with a
call to ClasslLoaderManager.
On 11 Apr 2016, at 15:47, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent(a)massol.net> wrote:
I’m not really familiar with namespaces. Is there a java class to represent them?
> 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.
Do we have that? We’ll need a Namespace object anyway for that to work
out (as otherwise a String is too generic for a component type), do we have such an
object?
There is no Namespace object right now.
So it means that we’d need component implementation that accepts Namespaces as input
(instead of Entity Reference) for everything we need (permissions, etc) since I guess we
shouldn’t consider that a namespace points to an entity reference.
It's more generic than entity reference yes. Also it's meant to
describe a scope/context more than an entity to manipulate.
Let’s hope we’ll have the use case for namespaces one day because right now, they look
very much like Entity References or Link Resource References (doc:…, space:…, wiki:…,
user:…), we’re starting to have a lot of various types of references in XWiki ;)
Not sure what you mean. Namespaces are not a new thing. Extensions,
classloaders and components are based on namespaces. Since webjars are
extensions installed in some namespace (or core extensions) it seems
more consistent to have the webjars entry point be based on namespaces
too.
We have only namespaces at xwiki-commons level.
Also, right now it means I cannot set the wiki id in the context and I hope this won’t
cause any problem in any API I call in WebJarsResourceReferenceHandler. Right now there’s
no valid way of extracting a wiki id from a namespace (because a namespace can be anything
and doesn’t always contain a wiki id). Of course, I could check if the namespace starts
with “wiki:” but that’s not very nice, the WebJarsResourceReferenceHandler code shouldn’t
know the format of a namespace.
WebJarsResourceReferenceHandler job is to extract a resource from a
classloader, if there is an issue caused by whatever wiki is located
in the context (I guess the context will end up on whatever wiki
correspond to the domain) I would say it's a bug to fix but it's
probably the kind of thing that will be noticed quickly.
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
Thanks
> -Vincent
>
>> 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