How to prevent an object from being used where it shouldn't

Certified Senior Developer

Hi all, 

We need a rule expression to be used only in one process model.

How can we prevent that rule expression from being used in another process model or interface? The only way I can think of is to manually check the dependencies of that rule. Could this review of dependencies be automated in some way?

Thanks in advance. 

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    I do not see a way to prevent that. This feels like an awkward design decision. I am curious. Why is that?

    Instead of writing an expression, you could put that code into a script task. This is not exactly a best practice, but might be an option for your specific case.

  • 0
    Certified Senior Developer
    in reply to Stefan Helzle

    It is due to a security requirement. We have to store access tokens to client services in Appian database and we have to prevent a query to this table from being used from the Appian front-end. For this, we intend for this query to be done only from a specific process.

  • 0
    Certified Lead Developer
    in reply to JJ Cañas

    Without knowing the details, but for me, this feels more like obscurity than security.

    So this is not about the expression, but about restricting access to certain items in a database, correct?

    I suggest to contact Appian for ideas about how to do this. If you do that, maybe you could share some details here.

  • This does sound like strange security configuration.  Otherwise, one suggestion would be to restrict access to this area of the database to a specific DB account, and utilize the Query Database Service in this process to retrieve your token.  In this case, you can setup a custom data source directly within this one Query DB node, which can be the only place that has the password to the account that can access the tokens.

    Of course, developers may be able to copy/paste this node from the model (we would have to test if this brings the PW along also, maybe not?), but would be less obvious than using an admin console connection and expression rule.  It is still "Security by Obscurity" however.

Reply
  • This does sound like strange security configuration.  Otherwise, one suggestion would be to restrict access to this area of the database to a specific DB account, and utilize the Query Database Service in this process to retrieve your token.  In this case, you can setup a custom data source directly within this one Query DB node, which can be the only place that has the password to the account that can access the tokens.

    Of course, developers may be able to copy/paste this node from the model (we would have to test if this brings the PW along also, maybe not?), but would be less obvious than using an admin console connection and expression rule.  It is still "Security by Obscurity" however.

Children