> On 11 Apr 2016, at 19:21, Thomas Mortagne <[email protected]> wrote: > > 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.
FTR, I really don’t like utils classes. IMO this is a sign that we need a NameSpace object and some serializer component impl. BTW just found that Marius had already added a method in the ScriptService for webjars: https://github.com/xwiki/xwiki-platform/blob/4f2f6fa823d3d222851f7001237b0bd5cee2d242/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/script/WebJarsScriptService.java#L264-L264 Thanks -Vincent > 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
