Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #2339 (closed)

Opened 11 years ago

Closed 9 years ago

BUG: Cannot change active group while working in application

Reported by: atarkowska Owned by: atarkowska
Priority: blocker Milestone: OMERO-4.4
Component: Security Version: n.a.
Keywords: n.a. Cc: python-team@…, jburel
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: n.a.
Sprint: n.a.

Description

Cannot change active group. Perhaps server could handle that better to be sure nothing stops user to switch between groups.

Fri, 07 May 2010 11:58:18 wrapper      ERROR    Traceback (most recent call last):
  File "/Users/ola/Dev/omero/components/tools/OmeroWeb/omeroweb/extlib/gateway.py", line 126, in changeActiveGroup
    self.c.sf.setSecurityContext(omero.model.ExperimenterGroupI(gid, False))
  File "/Users/ola/Dev/omero/dist/lib/python/omero_API_ice.py", line 197, in setSecurityContext
    return _M_omero.api.ServiceFactory._op_setSecurityContext.invoke(self, ((obj, ), _ctx))
SecurityViolation: exception ::omero::SecurityViolation
{
    serverStackTrace = ome.conditions.SecurityViolation: SecurityContext change cancelled:
Client 61001815-3907-48a7-8b43-24dcfd9fee5e has active stateful services: count=27

	at ome.services.sessions.events.ChangeSecurityContextEvent.throwIfCancelled(ChangeSecurityContextEvent.java:61)
	at ome.services.sessions.SessionManagerImpl.setSecurityContext(SessionManagerImpl.java:1091)
	at ome.services.blitz.impl.ServiceFactoryI.setSecurityContext(ServiceFactoryI.java:312)
	at omero.api._ServiceFactoryDisp.___setSecurityContext(_ServiceFactoryDisp.java:385)
	at omero.api._ServiceFactoryDisp.__dispatch(_ServiceFactoryDisp.java:1347)
	at IceInternal.Incoming.invoke(Incoming.java:159)
	at Ice.ConnectionI.invokeAll(ConnectionI.java:2037)
	at Ice.ConnectionI.message(ConnectionI.java:972)
	at IceInternal.ThreadPool.run(ThreadPool.java:577)
	at IceInternal.ThreadPool.access$100(ThreadPool.java:12)
	at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:971)

    serverExceptionClass = ome.conditions.SecurityViolation
    message = SecurityContext change cancelled:
Client 61001815-3907-48a7-8b43-24dcfd9fee5e has active stateful services: count=27

}

Change History (23)

comment:1 Changed 11 years ago by jmoore

  • Cc jburel cxallan added
  • Owner changed from jmoore to atarkowska

#2196 specified the work for this. In discussion with Chris, it was decided that if there is an active stateful service, it will most likely not handle the security context change well. Ola, I'm passing this back to you. We'll need to decide what semantics we can allow, and once we've done that, we'll need tests.

comment:2 Changed 11 years ago by atarkowska

In my opinion there should be a specific method to change active group on the server side which handle specific use case.

comment:3 Changed 11 years ago by atarkowska

  • Owner atarkowska deleted

comment:4 Changed 11 years ago by jmoore

I'm happy to be proved wrong, but I think that the logic of how/when/which stateful services should be closed belongs in the client. You almost certainly want to ask the user "did you remember you were doing X? Save or don't save?" If you know that none of that is the case, then we can off a closeAllStatefulServices() which does the same as closeSession(), but as I mentioned on Skype, I consider having stateful services just hanging around a bug.

comment:5 Changed 11 years ago by jmoore

  • Sprint changed from 2010-04-30 (8) to 2010-05-13 (9)

comment:6 Changed 11 years ago by cxallan

  • Sprint changed from 2010-05-13 (9) to 2010-05-27 (10)

comment:7 Changed 11 years ago by cxallan

  • Sprint changed from 2010-05-27 (10) to 2010-06-10 (11)

comment:8 Changed 11 years ago by jburel

  • Sprint changed from 2010-06-10 (11) to 2010-06-24 (12)

comment:9 Changed 11 years ago by jmoore

  • Milestone OMERO-Beta4.2 deleted
  • Sprint 2010-06-24 (12) deleted
  • Summary changed from BUG: Cannot change active group while working in appliation to BUG: Cannot change active group while working in application

It's probably not necessary (nor wise) to be changing this at the moment. Let's re-evaluate later in the 4.2 series.

comment:10 Changed 11 years ago by jmoore

  • Milestone set to Unscheduled

comment:11 Changed 11 years ago by jmoore

(In [7817]) Adding omero.client.getStatefulServices() to all OmeroClients for better test cleanup. (See #1736, #2339)

comment:12 Changed 10 years ago by jmoore

(In [8402]) Modifying setSecurityContext test to pass (See #2339, #3189)

Two services were not closed and therefore the exception
is expected. See comments in test for more information.

comment:13 Changed 9 years ago by jmoore

  • Cc python-team@… added; cxallan removed
  • Milestone changed from Unscheduled to OMERO-Beta4.4
  • Owner set to wmoore

This has come up again on the forums. https://www.openmicroscopy.org/community/viewtopic.php?f=6&t=951 At least as a part of the method gateway.changeActiveGroup() we should decide how to handle this and state it in the docs. Is the client required to loop through the contents of getStatefulServices -- I'm certainly fine with that, but we need to be careful that these services aren't being left open by us (e.g. some method that opens a search internally and leaves it handling)

Passing to Will for his thoughts since he hasn't been CC'd on this yet.

comment:14 Changed 9 years ago by cneves

All the services created using the connection wrappers are available under conn._proxies. We might want to iterate them and close as needed on the changeActiveGroup call. Alternatively setting self._proxies = NoProxies() will mark all services to be garbage collected, but this may not be enough.

comment:15 Changed 9 years ago by jmoore

Cool, thanks Carlos. For me the key is: do we know that the user/client understands that all extant stateful services are about to be closed? I assume this is handled at the web level at the moment, but will need to be clear at the gateway level as well.

comment:16 Changed 9 years ago by cneves

Probably a flag on changeActiveGroup called {{ forceStatefulClose }} or something alike, and proper capture of the exceptions thrown if one fails to do so (basically catch SecurityException?) and re-raise of an exception (maybe the same) with a comment "Stateful services open, please close them prior to changing groups or call with forceStatefulClose=True" ?

comment:17 Changed 9 years ago by wmoore

I think that Carlos' proposal for the Gateway behavior sounds fine.

For the web, I think I'd be happy to force closure of all stateful services with the exception of any that have jobs running (E.g. Delete or Scripts). Currently, our only handle of jobs in the web is the request.sessioncallback?. I guess we could check this before forcing changeGroup, but it would be nicer if we could ask the server "are there any jobs running now?"

comment:18 Changed 9 years ago by wmoore

  • Owner changed from wmoore to jmoore

Josh - returning to you: This sounding reasonable now?

comment:19 Changed 9 years ago by jmoore

Will, the exception you mention is the important point. We can certainly add another method to return just the "important" stateful services (though I still think that's very hard to specify from the server-side), but for the moment it's pretty straight-forward to check the open stateful services and check their type: if it's a DeleteHandle or a ScriptProcessor then you'll have to handle it. But that just brings us back to the question of what to do, and the forceStatefulClose won't help.

Any chance of you guys discussing that this afternoon?

comment:20 Changed 9 years ago by jmoore

  • Owner changed from jmoore to jburel

comment:21 Changed 9 years ago by jburel

Currently in insight, users can only change group when on-going tasks are completed e.g. import.
When the user changes group, all services e.g. re, pixels store, etc., are closed. Prior to that the user is notified and has the option to save changes. The UI is totally refreshed and data from new group are loaded.

I am going to investigate a possible new workflow for change group where a user will have the ability to have 2 groups displayed at the same and moving between them w/o having to shutdown services.

comment:22 Changed 9 years ago by jburel

  • Owner changed from jburel to atarkowska

Passing to Ola for web addition if required, otherwise it can be closed

comment:23 Changed 9 years ago by atarkowska

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

Webclient simply create new session when user wants to switch to the new group. Old session should be killed by the server when is no longer used. There are various solution already offered in the web to move data between groups. Currently tree filter data for P/D/I, but I do not see any problem with loading Group/User?/P/D/I instead. It is only important to know how to modify session be able to get those data from the server. Is just one/two more levels - very easy to support. Closing ticket.

Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.91136 sec.)

We're Hiring!