On Mon, Apr 11, 2016 at 6:38 PM, Vincent Massol <[email protected]> wrote: > ok thanks for the help Thomas, I understand now and it seems like a good idea > to support namespaces right now. >
> One question though: do we have some tools to generate a namespace? In the > getURL() method of the ScriptService, I’ll need to convert the current wiki > id into a namespace and I’d rather not hardcode it if possible. 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 <[email protected]> wrote: >> >> On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <[email protected]> wrote: >>> >>>> On 11 Apr 2016, at 15:47, Thomas Mortagne <[email protected]> >>>> wrote: >>>> >>>> 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”). >>> >>> 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 <[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
