Ticket #978 (closed Defect: duplicate)

Opened 4 years ago

Last modified 4 years ago

Privileged access and assignments to workspace topics needed

Reported by: Malte Owned by: jri
Priority: Blocker Milestone: Release 4.8.1
Component: DeepaMehta Standard Distribution Version: 4.8
Keywords: Cc:
Complexity: 1 Area: Application Framework / API
Module: deepamehta-accesscontrol

Description (last modified by Malte) (diff)

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!

Change History

comment:1 Changed 4 years ago by 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...

comment:2 Changed 4 years ago by 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!

comment:3 Changed 4 years ago by Malte

  • Description modified (diff)
  • Summary changed from extend privileged assignToWorkspace method to accept an URI to Privileged access and assignments to workspace topics needed

comment:4 Changed 4 years ago by 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.

comment:5 Changed 4 years ago by Malte

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

comment:6 Changed 4 years ago by Malte

  • Status changed from new to closed
  • Resolution set to duplicate

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.

comment:7 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by 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!

Note: See TracTickets for help on using tickets.