issue with SQLDataSource override

[claudiobosticco]

SmartClient Version: SNAPSHOT_v12.1d_2019-04-23/EVAL Deployment (expires 2019.06.22_07.35.36) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

Hello, I'm trying to override SQLDataSource, because I want to add some security contraints commons to many dataSources, for the different operationTypes.
Hope that in this use case makes sense to override SQLDataSource.

The override is declared like this:

public class SecureDataSource extends SQLDataSource {

    public DSResponse execute(DSRequest req) throws Exception {
        System.out.println("operationType: " + req.getOperationType());
        final HttpServletRequest httpServletRequest = req.getHttpServletRequest();
        final boolean isClub = req.isUserInRole("ROLE_JOFC_CLUB_GENERIC", httpServletRequest);
        if (isClub) {
            // check the operationType and set criteria or values
        }
        return super.execute(req);
    }

and in the dataSource:

            serverConstructor="com.juve.jofc.SecureDataSource"

Then I call (from client) an updateData which uses a DMI:

        <operationBinding operationType="update" operationId="updateStato" serverMethod="updateStato" requiresRole="ROLE_OFFICE_CLUB" requires="true">
            <serverObject lookupStyle="new" className="com.juve.jofc.approvazione.ApprovazioneJOFCDMI"/>
        </operationBinding>

This is the log of the updateData payload:

    criteria:{
        ID_REC:4016
    },
    values:{
        ID_REC:4016,
        STATE_CODE:"PROPOSTA_ACCETTATA"
    },
    operationConfig:{
        dataSource:"JOFC_DOMANDE_AFFILIAZIONE",
        repo:null,
        operationType:"update",
        textMatchStyle:"exact"
    },
    componentId:"approvazioneJOFCGrid",
    appID:"builtinApplication",
    operation:"updateStato",
    oldValues:{
        STATO:"PRO",
        NAZIONE:"Bermuda",
        EMAIL:"fhgfhfg@fff.ks",
        MODIFIER_TIMESTAMP:new Date(1554385312000),
        STATE_CODE:"PROPOSTA_INVIATA",
        ID_REC:4016,
        ID_NAZIONE_FK:23,
        CREATOR_TIMESTAMP:new Date(1554385312000),
        HA_NULLA_OSTA:false,
        TELEFONO:"556546564",
        LOCALITA:"ddddd",
        NOME_FAN_CLUB:"dsffdsfdsdfs",
        N_INIZIALE_SOCI:55,
        DATA_PROPOSTA:new Date(1554328800000),
        _selection_53:false,
        _embeddedComponents_approvazioneJOFCGrid:null
    }
}

The problem is that in the execute method of my SecureDataSource class I see operationType 'fetch' instead of 'update'. Also I see only the criteria and no values, and also no operationId.
After, it enters my update DMI, where the operationType and the other parameters are correct.

Why is that? Am I doing something wrong?

[Isomorphic]

Please see the QuickStart Guide's explanation of the server-side flow: DataSource.execute() happens *after* DMI. Most likely what you are seeing here is a "fetch" DSRequest that is initiated in your DMI is going through execute().

This also makes execute() a poor place to put security checks that should abort an entire request. A better place is in an override of IDACall. However, see also the Declarative Security discussion in the QuickStart - the particular check you are doing can be achieved with just a declaration, as can many other related checks.

[claudiobosticco]

Please see the QuickStart Guide's explanation of the server-side flow: DataSource.execute() happens *after* DMI. Most likely what you are seeing here is a "fetch" DSRequest that is initiated in your DMI is going through execute().

I've got a breakpoint in the first line of my 'execute' override and another in the first line of the DMI and it stops in the DMI first

This also makes execute() a poor place to put security checks that should abort an entire request. A better place is in an override of IDACall. However, see also the Declarative Security discussion in the QuickStart - the particular check you are doing can be achieved with just a declaration, as can many other related checks.

I need to do something like:



but with a more complex logic.
I'd prefer a more centralized solution which would work for all operation bindings, regardless of associated DMI or not.

Actually now I recall someone (maybe Blama ) posting something like your suggestion of overriding the IDACAll.
So is overriding the IDACAll acceptable for this use case?
Thanks

[Isomorphic]

Not clear why you mentioned that the DMI is first. That's exactly what we told you... were you just confirming?

Yes, IDACall would be a place to put centralized logic that should run before any DMIs.

[claudiobosticco]

Not clear why you mentioned that the DMI is first. That's exactly what we told you... were you just confirming?

Sorry, I wanted to write that it stops in the execute first, then in the DMI.

Yes, IDACall would be a place to put centralized logic that should run before any DMIs.

thanks, now I'm trying this approach, works fine.

[Isomorphic]

No, that’s not correct. The order is DMI first, then execute(). Consider that when you run dsRequest.execute() in a DMI, then SQLDataSource.execute() is downstream of that.

But yes, the correct place for the security logic that affects multiple DMIs is before DMI is run, such as in IDACall.