[xwiki-devs] [Proposal] New Webjars URL format to support relative webjars URL
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
+1 Thanks, Marius On Fri, Apr 8, 2016 at 10:06 AM, Vincent Massol <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
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). On Fri, Apr 8, 2016 at 9:06 AM, Vincent Massol <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd... 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/…”. Maybe this is too much for now. It’s more work and I’m not sure about the use cases... Thanks -Vincent
On Fri, Apr 8, 2016 at 9:06 AM, Vincent Massol <vincent@massol.net> 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
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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.
Thanks -Vincent
On Fri, Apr 8, 2016 at 9:06 AM, Vincent Massol <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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? 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 <vincent@massol.net> 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
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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?
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? 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 <vincent@massol.net> 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
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 11 Apr 2016, at 15:47, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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? 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? 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. 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 ;) 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.
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? 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 <vincent@massol.net> 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
On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:47, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote:
> On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd...
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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:47, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote: > >> On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd... >
> 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 <vincent@massol.net> 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
On Mon, Apr 11, 2016 at 6:38 PM, Vincent Massol <vincent@massol.net> 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 <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:47, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote:
> > On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote: > > On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote: >> >>> On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd... >> > >> 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 <vincent@massol.net> 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 11 Apr 2016, at 19:21, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 6:38 PM, Vincent Massol <vincent@massol.net> 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/4f2f6fa823d3d222851f7001237b0bd... Thanks -Vincent
Thanks
-Vincent
On 11 Apr 2016, at 18:00, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 5:32 PM, Vincent Massol <vincent@massol.net> wrote:
On 11 Apr 2016, at 15:47, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Mon, Apr 11, 2016 at 3:11 PM, Vincent Massol <vincent@massol.net> wrote:
> On 11 Apr 2016, at 15:07, Vincent Massol <vincent@massol.net> wrote: > >> >> On 08 Apr 2016, at 10:42, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote: >> >> On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <vincent@massol.net> wrote: >>> >>>> On 08 Apr 2016, at 10:00, Thomas Mortagne <thomas.mortagne@xwiki.com> 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/4f2f6fa823d3d222851f7001237b0bd... >>> >> >>> 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 <vincent@massol.net> 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
participants (3)
-
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol