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. 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
