On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <[email protected]> wrote: > >> On 11 Apr 2016, at 15:07, Vincent Massol <[email protected]> wrote: >> >>> >>> On 08 Apr 2016, at 10:42, Thomas Mortagne <[email protected]> wrote: >>> >>> On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <[email protected]> wrote: >>>> >>>>> On 08 Apr 2016, at 10:00, Thomas Mortagne <[email protected]> >>>>> 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/4f2f6fa823d3d222851f7001237b0bd5cee2d242/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/internal/WebJarsResourceReferenceHandler.java#L120-L120 >>>> >>> >>>> 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 > >> 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 <[email protected]> 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
