Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Are there changes to ds.xml's "requiresRole" (for server requests) in 5.1d?

    Hello Isomorphic,

    I'm getting an error in my application telling me that the logged in user does not have a specific role, which is true (uses does not have one of the roles). (PLEASE SEE MY OWN REPLY, preconditions changed)
    But this request (to be piggybacked in addRelatedUpdate() later on) was started on the server, not the client. This worked fine in 4.1p from 2015-03-25. Are there any changes in 5.1d 2015-03-25 (bugfix or intentional) that could lead to failure of a server started DSRequest?
    Error log:
    Code:
    === 2015-03-27 19:40:01,316 [ec-6] WARN  RequestContext - dsRequest.execute() failed: 
    java.lang.SecurityException: DataSource 'xxx', operationType 'fetch', operationId 'null'.  This operation requires role(s) 'a, b, c'. User '1310'fails the role check.
    	at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:2428)
    	at com.lmscompany.lms.server.worker.QUERY_VIEW.queryDS(QUERY_VIEW.java:40)
    ...
    ...
    QUERY_VIEW.java line 40 is: DSResponse fetchResponse = fetchRequest.execute();
    Lines before are:
    Code:
    public class QUERY_VIEW {
    	@SuppressWarnings("unchecked")
    	static DSResponse queryDS(RPCManager rpcManager, DatasourceEnum dataSource, String operationId, String afterOperationType,
    			final Object criteriaFieldValueOrValueList) throws Exception {
    
    		ArrayList<Long> valueList = null;
    		Long valueSingle = null;
    		final DSRequest fetchRequest = new DSRequest(dataSource.getValue(), DataSource.OP_FETCH, rpcManager);
    		if (operationId != null)
    			fetchRequest.setOperationId(operationId);
    
    		if (criteriaFieldValueOrValueList instanceof ArrayList) {
    			valueList = (ArrayList<Long>) criteriaFieldValueOrValueList;
    			fetchRequest.setAdvancedCriteria(new AdvancedCriteria(DefaultOperators.And.getID(), new Criterion[] { new SetCriterion(fetchRequest
    					.getDataSource().getPrimaryKey(), DefaultOperators.InSet.getID(), valueList) }));
    		} else if (criteriaFieldValueOrValueList instanceof Long) {
    			valueSingle = (Long) criteriaFieldValueOrValueList;
    			fetchRequest.setCriteria(fetchRequest.getDataSource().getPrimaryKey(), valueSingle);
    			valueList = new ArrayList<Long>();
    			valueList.add(valueSingle);
    		}
    
    		DSResponse fetchResponse = fetchRequest.execute();
    The RPCManager used is the one from the client request, but until now, this worked fine.
    Do you have an idea what is happening here?

    Thank you & Best regards,
    Blama
    Last edited by Blama; 27 Mar 2015, 11:45.

    #2
    Sorry, I got to correct myself: The user DOES have all three roles listed in the fetch OperationBinding in the .ds.xml (and many more).
    This binding is also called successfully from the client. So what does not work is the call from the server DSRequest, for reasons unknown.

    Just to be sure: Only the IDACall or its subcalls checks for the role-stuff, not SQLDataSource or its subclass. Therefore, role checks as only done for client requests. Correct?

    Best regards,
    Blama

    Comment


      #3
      We have made a few changes to the way declarative security can be used in 5.1. One change introduced this behaviour but we've since rethought this and a new build will be available in the next few days with this behaviour reverted for server side initiated requests.

      Regards,
      Isomorphic Software

      Comment


        #4
        Hi Isomorphic,

        could you please update here once you reverted the settings?
        Is there somewhere a overview-list of changes from 5.0p->5.1d? I don't mean new functionality, but changes to existing behaviour.
        That way I could see on a high level if I'll need any adjustments to my code.

        Even if you rollback this change (and assuming the change worked like you expected): Is it generally to expect to have to rework valid-usage code after a framework update?

        Best regards,
        Blama

        Comment


          #5
          There are no intentional behavior changes in this area from 5.0 to 5.1. This is simply a bug.

          Comment


            #6
            Hi Isomorphic,

            this is reverted for me using today's version.

            Thank you & Best regards,
            Blama

            Comment

            Working...
            X