Best method to verify multi-level relational dependencies

Question

Suppose you have entities A, B, C and D.

• D relates to C
• C relates to B
• B relates to A

Furthermore, user is only allowed to operate on D, if user owns A.

At a certain state in an application, you include a link to a page, which accesses D. Thus, you includes D's ID as a GET or POST parameter.

If user clicks on the link, the application retrieves D's ID and begins to operate on D.

Simple apps use URLs like this [modulo URL-rewriting]:

http://www.myServer.com/?action=1234&entity=D&ID=23

How to verify if user is allowed to operate on D?

A) The obvious solution would be this: Given D, find C, then find B and eventually find A. If the chain breaks somewhere, access to D would be rejected. Unfortunately, this requires - if trivially implemented - 4 database accesses instead of just the one for A.

B) Another solution would be to keep D's ID in the current session in a set of accessible entities to be used by the next page to be rendered.

C) As an alternative, one could encrypt GET and POST parameters somehow. On each page request, the first operation would be to decrypt the request's parameters. If the decrypt operation fails, access would be denied.

D) Or, at infinitum, hash all links in all pages, keep a map in the session which associates the hashes with the URLs and write only hashes to webpages.

E) Finally, you could keep references to A, B and C in D, references to A and B in C, references to A in B. Thus, at each level, one would be able to find immediately the root entity.

What's your solution in such a situation? And why?

Although I included the PHP tag, I'm don't want to focus this question to a language. I'd be happy to get general proposals. Or solutions, which are already implemented in e.g. ORM layers.

UPDATE-1

Finally, I have chosen D).

General principle:

Ensure, that IDs of somehow subordinate entities always get passed in a secure/trusted way. In such a way, that a third party isn't able to change their values.

Details:

This option provides many benefits by design:

First, IDs or other parameters of the linked pages never reach the browser. Instead of

http://www.myServer.com/?action=1234&entity=D&ID=23

most pages gets linked like this

http://www.myServer.com/?forwardHash=78sd7sdf98asd7ad5aa76asa4a465

All parameters of the next page to be executed are fully kept inside the user's session.

Since all parameters of pages are kept inside the user's session, far less checking is needed. Especially, the above mentioned relational dependency checks aren't any longer of use. If something is in the user's session, it has been put from a previously trusted dialog step.

Moreover, one can even force the user to only call those link available on the currently rendered page. Each time they call a link, the app may invalidate all other links of the page. Thus users won't be able to open pages in several windows and think, that they see two different 'state' of the application. If they call a link twice, the app may present an error message.

Finally, one may directly establish something I'd call sub-workflow dialogs: You would start the dialog by pushing the current page's URL on a continuation stack in the session and opening the edit dialog step. User may either orderly end or intentionally cancel the dialog workflow. A cancel workflow link may automagically appear as a user option, if the continuation stack isn't empty.

By keeping the continuation on a stack in the session, it gets fully isolated from the currently running dialog step. The dialog step not even knows anything about its caller.

By wrapping the functionality inside a small manager calls, the sub-process finally calls FlowManager::finishFlow(). This call pops a continuation from the stack and redirects the browser to this page - effectively returning to the point, where the workflow started.

Since we use a stack of continuations, one could even run sub-workflows which are subordinate to other sub-workflows.

Answer 1

The obvious solution would be this: Given D, find C, then find B and eventually find A. If the chain breaks somewhere, access to D would be rejected. Unfortunately, this requires - if trivially implemented - 4 database accesses instead of just the one for A.

I suppose that might be possible. It depends in part on what "relates to" means, but assuming a relatively straightforward schema, I'd expect you to be able to join all four tables in a single SQL statement. If part of the chain is missing, the query would return no rows.

Or am I missing something?

Answer 2

I'm not sure I understand what you want to achieve but can't you use option A, to verify if user is allowed to operate on D with only one access to the database?:

SELECT D.*
  FROM D
    JOIN C 
      ON C.id = D.cid
    JOIN B
      ON B.id = C.bid
    JOIN A.id = B.aid
WHERE A.ownedBy = @userID
  AND D.id = @idToBechecked