Question

I’m developing an iOS application that’s a manager/viewer for another project. The idea is the app will be able to process the data stored in a database into a number of visualizations– the overall effect being similar to cacti. I’m making the visualizations fully user-configurable: the user defines what she wants to see and adds restrictions.

She might specify, for instance, to graph a metric over the last three weeks with user accounts that are currently active and aren’t based in the United States.

My problem is that the only design I can think of is more or less passing direct SQL from the iOS app to the backend server to be executed against the database. I know it’s bad practice and everything should be written in terms of stored procedures. But how else do I maintain enough flexiblity to keep fully user-defined queries?

While the application does compose the SQL, direct SQL is never visible or injectable by the user. That’s all abstracted away in UIDateTimeChoosers, UIPickerViews, and the like.

Answer 1

Is all of the data in the database available to all of the users, or do you only permit each user to access a subset of the data? If the latter, simply restricting the database login to read-only access isn’t enough to secure your data.

As a trivial example, a user could compromise your interface in order to submit the query SELECT password, salt FROM users WHERE login = 'admin', hijack the response to get at the raw data, and brute force your admin password. As the popularity of an app grows, the pool of malicious users grows more than linearly, until eventually their collective intelligence exceeds that of your team; you shouldn’t put yourself in a situation where success will be your downfall.

You could take the SQL query sent by the client application and try to parse it server-side in order to apply appropriate restrictions on the query, to fence the user in, so to speak. But getting there would require you to write a mini SQL parser in your server code, and who wants to do all that work? It’s much easier to write code that can write SQL than it is to write code that can read it.

My team solved a similar problem for a reporting interface in a rather complex web application, and our approach went something like this:

Since you already intend to use a graphical interface to build the query, it would be fairly easy to turn the raw data from the interface elements into a data structure that represents the user’s input (and in turn, the query). For example, a user might specify, using your interface, the condition that they want the results to be confined to those collected on May 5, 2010 by everyone but John. (Suppose that John’s UserID is 3.) Using a variant of the JSON format my team used, you would simply rip that data from the UI into something like:

{ "ConditionType": "AND",
  "Clauses": [
    { "Operator": "Equals",
      "Operands": [
        { "Column": "CollectedDate" },
        { "Value": "2010-05-05" }
      ]
    },
    { "Operator": "NotEquals",
      "Operands": [
        { "Column": "CollectedByUserID" },
        { "Value": 3 }
      ]
    }
  ]
}

On the client side, creating this kind of data structure is pretty much isomorphic to the task of creating an SQL query, and is perhaps somewhat easier, since you don’t have to worry about SQL syntax.

There are subtleties here that I’m glossing over. This only represents the WHERE part of the query, and would have to live in a larger object ({ "Select": ..., "From": ..., "Where": ..., "OrderBy": ... }). More complicated scenarios are possible, as well. For example, if you require the user to be able to specify multiple tables and how they JOIN together, you have to be more specific when specifying a column as a operand in a WHERE clause. But again, all of this is work you would have to do anyway to build the query directly.

The server would then deserialize this structure. (It’s worth pointing out that the column names provided by the user shouldn’t be taken dirty – we mapped them onto a list of allowed columns in our application; if the column wasn’t on the list, deserialization failed and the user got an error message.) With a simple object structure to work with, making changes to the query is almost trivial. The server application can modify the list of WHERE clauses to apply appropriate data access restrictions. For example, you might say (in pseudo-code) Query.WhereClauses.Add(new WhereClause(Operator: 'Equals', Operands: { 'User.UserID', LoggedInUser.UserID } )).

The server code then passes the object into a relatively simple query builder that walks the object and splits back an SQL query string. This is easier than it sounds, but make sure that all of the user-provided parameters are passed in cleanly. Don’t sanitize – use parameterized queries.

This approach ultimately worked out really nicely for us, for a few reasons:

1. It allowed us to break up the complexity of composing a query from a graphical interface.
2. It ensured that user-generated queries were never executed dirty.
3. It enabled us to add arbitrary clauses to queries for various kinds of access restrictions.
4. It was extensible enough that we were able to do nifty things like allowing users to search on custom fields.

On the surface, it may seem like a complex solution, but my team found that the benefits were many and the implementation was clean and maintainable.