The Open Anzo Project

Semantic Application Middleware

  • Home
  • Community
  • License
  • About
Sponsors
Cambridge Semantics Inc.

Ticket #90 (closed defect: fixed)

Opened 1 year ago

Last modified 9 months ago

inconsistant reset permissions depending on protocol

Reported by: jpbetz Assigned to: mroy
Priority: minor Milestone: 3.0 milestone1
Component: openanzo Version: 3.0
Keywords: security permissions reset Cc:

Description (Last modified by mroy)

WSModelService is able to reset the server after the default user is removed but JMSModelService is not.

This can easily be tested by modifying AbstractTest?.reset to use JMSModelService and then run TestTrackers?.testRemoveUserFromNotification a few times.

Reset works for both protocols if reset looks something like this: 

protected void reset(Collection<Statement> stmts) throws AnzoException{
    Properties props = new Properties(System.getProperties());
    props.putAll(properties);
    ServicesProperties.setUser(props, "sysadmin");
    ServicesProperties.setPassword(props, "123");
    JMSModelService service=new JMSModelService(this,props);
    service.reset(stmts);        
}

Change History

11/03/07 08:36:30 changed by mroy

This is a known limitation of the JMS protocol for reset. The issue is that a JMS connection must be authenticated in order to establish the connection, and if there are tests or failures that cause the state of the server's authentication information to become unstable or inconsistent, then there is no way for a client to connect in order to call the reset command. The above example for a fix will only work if tests never modify the sysadmin user/password and the server never fails in such a way that the authentication information gets corrupted. That is why the Abstract tests were rewritten to use the webservice endpoint to call reset, since it is possible to allow a webservice/rest call to occur without forcing authentication. Since reset is a mechanism only designed for testing, I don't believe it is required to make the JMS endpoint support unauthenticated connections just to support reset.

11/03/07 15:20:19 changed by jpbetz

Using WS for reset seems fine. Are we expecting open anzo users to use reset in their testing? If so, I think it's a problem to provide a JMS reset implementation that seems to work in some situations but not in others.

11/03/07 15:21:03 changed by jpbetz

  • owner changed from jpbetz to mroy.

assigning to mroy per question in comment 2

11/03/07 22:44:48 changed by jpbetz

What I'm really wondering is:

Why have a reset on the JMS implementation at all? If we don't use it and it's problematic, wouldn't it be better to just have one on the WS impl? Seems like it would be easier to explain to users that WS is the only protocol supporting reset than that the JMS protocol has reset but has these various issues and limitations...

03/31/08 10:13:56 changed by mroy

  • status changed from new to closed.
  • resolution set to fixed.
  • description changed.

Resolved based on ldap authorization usage.

  • Home
  • Community
  • License
  • About
Copyright © 2007 - 2008 OpenAnzo.org