Privileged access and assignments to workspace topics needed

[Malte]

In my case i want ordinary users (authenticated) to not be eligible to publish topics (simply create topics in a "Public" or "Common" workspace) but instead assign their submitted (topic with all its childs and relating assocs) to a "Collaborative" workspace first.

Members of the "Collaborative" workspace can then, after reviewing the submitted information to a "Public" Workspace.

The problem i have now is that a user not member of the collaborative workspace has not the permission to assign their topics to the collaborative workspace.

So, extending the privileges of the following two methods would do the trick for me:

dms.getAccessControl().getWorkspace(collaborativeWorkspaceId)

dms.getAccessControl().assignToWorkspace(collaborativeWorkspaceId)

I think this would be the way we would want to realize a "publication" workflow while completely relying on our existing ACL concept.

What do you think? Thanks for your help!

[Malte]

Sorry for the confusion again. I guess i could just use the privileged dms.getAccessControl().getWorkspace(uri) call instead of the one from workspaceService.getWorkspace(uri) and that should do the trick...

[Malte]

Well, unexpectedly this does not work either. Despite the plugin uses the privileged? AccessControl? from the dm4-core, the request to read the "collaborative" workspace id fails.

SCHWERWIEGEND: Request "GET /website/user/menu" failed. Responding with 401 (Unauthorized). The original exception/error is:
java.lang.RuntimeException: Fetching topic failed (key="uri", value="de.kiezatlas.ws_confirmation")
	at de.deepamehta.core.impl.EmbeddedService.getTopic(EmbeddedService.java:115)
	at de.deepamehta.core.impl.AccessControlImpl.getWorkspace(AccessControlImpl.java:137)
	at de.kiezatlas.website.WebsitePlugin.getPrivilegedWorkspace(WebsitePlugin.java:1115)
	at de.kiezatlas.website.WebsitePlugin.isConfirmationWorkspaceMember(WebsitePlugin.java:746)
	at de.kiezatlas.website.WebsitePlugin.getWebsiteMenu(WebsitePlugin.java:125)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:622)
	at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
	at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)
	at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
	at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
	at com.sun.jersey.server.impl.uri.rules.ResourceObjectRule.accept(ResourceObjectRule.java:100)
	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
	at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1480)
	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1411)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1360)
	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1350)
	at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538)
	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:339)
	at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:300)
	at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:93)
	at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:50)
	at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:31)
	at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:76)
	at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:49)
	at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:501)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
	at org.eclipse.jetty.server.Server.handle(Server.java:370)
	at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
	at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)
	at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
	at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
	at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
	at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
	at java.lang.Thread.run(Thread.java:701)
Caused by: de.deepamehta.core.service.accesscontrol.AccessControlException: user "malte" has no READ permission for object 1706219
	at de.deepamehta.plugins.accesscontrol.AccessControlPlugin.checkReadPermission(AccessControlPlugin.java:803)
	at de.deepamehta.plugins.accesscontrol.AccessControlPlugin.preGetTopic(AccessControlPlugin.java:430)
	at de.deepamehta.core.impl.CoreEvent$1.deliver(CoreEvent.java:32)
	at de.deepamehta.core.impl.EventManager.deliverEvent(EventManager.java:97)
	at de.deepamehta.core.impl.EventManager.fireEvent(EventManager.java:63)
	at de.deepamehta.core.impl.EmbeddedService.fireEvent(EmbeddedService.java:531)
	at de.deepamehta.core.impl.EmbeddedService.checkAccess(EmbeddedService.java:747)
	at de.deepamehta.core.impl.EmbeddedService.instantiateTopic(EmbeddedService.java:653)
	at de.deepamehta.core.impl.EmbeddedService.getTopic(EmbeddedService.java:113)
	... 55 more

While i can confirm that "1706219" is the ID of the collaborative workspace in question. I would be glad if someone could clarify if this is a bug or the method/service i am using is not a "privileged"/the correct one.

Thanks!

[jri]

In current 4.8.1-SNAPSHOT this call is privileged:

dms.getAccessControl().getWorkspace(workspaceUri)

See ticket:963#comment:4 (5 weeks ago).

Your stacktrace shows me you're still working with DM 4.7.
This will not work.

[Malte]

Yes, 4.7. OK, thank you very much for the clarification.

[Malte]

Upgrading to 4.8.1 did make my issue go away though this "publication" workflow, creating and assigning a new topic into a collaborative/confidential/private workspace which is neither read- or writeable for the requesting user is tricky.

Just to mention a few things you will have to have in mind for this:

• if no workspace assignment exists for an object, no exception is raised, that makes all this possible in first place
• always check if a workspace assignment for an object exists (e.g. if your composite may have references to other topics already public/pulished) but especially when using the privileged assignToWorkspace() (otherwise the latter creates many ws assignments which is not what we want)
• assign associations first, then the topics (otherwise you could not fetch the association in between the two topics anymore), the case when you do not have a RelatedTopic? (and topic.getRelatingAssociation()) at hand (see #981)
• the uppermost parent composite topic needs to be assigned at the very last (e.g. consider the case where write facets to it, the composite topic must have no workspace assignment for this to succeed, otherwise an an exception is thrown)

I am closing this ticket as the issue described here was already addressed with solving #963.

[Malte]

Now i am just wandering how to turn a privileged workspace assignment into an ordinary one without leaving two standing. If the wsService.assignToWorkspace() (which should work in my publication case, as editors are members of both workspaces) also deletes a previous privileged workspace assignment - then i'll be fine with what we have. Otherwise i would need to be able to delete the old workspace assignment manually (for which i guess there is currently no method). I will find out the details here tomorrow and see if using the WorkspaceService?.assignToWorkspace() does the trick as it is.

[Malte]

Just wanted to let you know:

workspaceService.assignToWorkspace()

deletes and creates a new assignmnent, also if that one is privileged. So, works very fine. Thanks!