Re: [xwiki-devs] [Proposal] New Webjars URL format to support relative webjars URL

On 11 Apr 2016, at 19:21, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: On Mon, Apr 11, 2016 at 6:38 PM, Vincent Massol <vincent(a)massol.net> wrote: The is no platform level helper for this no. Been lazy on this. I guess some platform side internal NamespaceUtils (extending org.xwiki.component.namespace.NamespaceUtils) with toWikiNamespace(String wikiId) would do for now.

Thanks > -Vincent > >> On 11 Apr 2016, at 18:00, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >> >> On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >>> >>>> On 11 Apr 2016, at 15:47, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >>>> >>>> On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >>>>> >>>>>> On 11 Apr 2016, at 15:07, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >>>>>> >>>>>>> >>>>>>> On 08 Apr 2016, at 10:42, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: >>>>>>> >>>>>>> On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: >>>>>>>> >>>>>>>>> On 08 Apr 2016, at 10:00, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; 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”). >>> >>> I’m not really familiar with namespaces. Is there a java class to represent them? >>> >>>> 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? >> >> 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. >> >>> 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. >>> >>> 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. >> >>> >>> Thanks >>> -Vincent >>> >>>> 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 &lt;vincent(a)massol.net&gt; 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