Skip to Content

Parameterized data objects in Jitterbit App Builder

In typical scenarios, developers restrict access to rows using the data object's WHERE clause. This occurs at design-time. The data object may be constrained at run-time by panel or page binding criteria. For instance, a single-row panel must be bound in such a way that the data object returns one-and-only-one row. Regardless, the user has permission to view any row in the given data object, provided it's not excluded by the data object's WHERE clause.

In some scenarios, however, developers may need to restrict access to data object rows at design-time based on binding criteria supplied at run-time. In these scenarios, the user should only be able to access rows that he or she can identify.

For example, imagine a self-registration application that allows users to create accounts. The application sends an email to a user-supplied email address. The email contains a link back to the self-registration application. The link itself contains a secret token which is passed as binding criteria to the confirmation page. This allows the user to view and confirm his or her pending registration.

In the self-registration scenario, the developer needs to ensure that the confirmation page's data object is bound by the secret token. Otherwise, a malicious user could simply remove the secret token from the URL to view other pending registrations. This would allow the user to confirm a registration for an email address to which he or she does not have access.

To prevent that from happening, the developer needs to ensure that the user provides his or her secret token when querying the pending confirmations. This can be achieved using a parameterized data object.

To create a parameterized data object, the developer must indicate that one or more columns are "binding". At runtime, prior to executing the Filter event, App Builder will assert that the client has supplied values for each binding column. If a binding column value has not been supplied, App Builder will throw an exception. This prevents users–malicious or otherwise–from executing a query that retrieves every row from the data object. In the self-registration example, the user user can only retrieve a pending confirmation if he or she already knows the secret token.

Known issues and limitations

  • Developers cannot use the Results view to query a parameterized data object. The Results view is executed without any binding criteria.
  • Parameterized data object Events cannot be scheduled. App Builder does not supply binding criteria when querying the scheduled Event's data object.