Forum OpenACS Development: Response to Sub-package site nodes API thought

Collapse
5: Response to Sub-package site nodes API thought (response to 1)
Posted by Lars Pind on 05/31/02 10:13 AM
Explanation of "encoding parameter names":

Say you have this partial set of nodes inside the acs-subsite package: (parentheses contain parameters) 

* ss_ermissions (object_id, party_id)
And this is from bug-tracker: 
* bt_index (status, priority, severity, party_id, component)
  * bt_admin ()
Say the path taken is: Go to bug-tracker index page, do some filtering, then go to the admin page and click on the permissions link.

Now, first, we need a unique ID for each of these nodes. We can use something like the path of the file in the file system serving this node, with the caveat, that there may not always be a one-to-one relationship between nodes and files.

(Not sure about this. There'll definitely be files that aren't nodes (such as pages that just do something and then redirect), but will there also be the case of two files serving the same node? Perhaps.)

In order to shorten that site node ID, we could make it an integer, assigned automatically by the system at server startup (with the caveat, that these should stay the same across server restarts, so we better store them in the DB, actually).

The next part is the parameters. In the example, both Site Map and Permissions share the parameter "expand", hence if we want to pass that info as a URL parameter, we'll need to change its name.

The information we need to pass for the path that we traversed to get here is:

  • node_id of the site_node on which the bug-tracker was mounted.
  • intra-package node ID of the bt_admin node.
  • parameters for bt_admin node and all parent nodes.
For example: 
path_0_node_id=node-id-of-bug-tracker
path_0_intra_node_id=bt_admin
path_0_param_bt_index.status=open
path_0_param_bt_index.party_id=3
If your path has more entries (I'm thinking one entry per "jump" you make outside the hierarchy defined by the site map and the intra-package site nodes), we'd have path_0_... path_1_..., etc.

So, specifically, the encoding of parameter names I'm talking about is the encoding of "status" as "path_0_param_bt_index.status", in order to avoid name clashes with the "status" parameter of hte bt_index page, and any other status parameters that any other page, including the current one, may take.

Another thing I just thought of is that if all page have some sort of ID, and you use those instead of a full url in the cases where we use return_url today, you also avoid the problem that Branimir mentioned in his post about cross-site-scripting, that you can redirect to http://youserver.com/bboard/delete-all?return_url=http://mysite.com/, thus disguising your action.

As far as issuing a new ID on every single request goes, how would you do that? You'd have to issue a redirect on each request, in order to get the browser to use a new ID, if it's in the URL. If it's in the cookie, you're defeating the purpose of letting people browse using two windows. I'm afraid that only viable option is to have long nasty URLs.

This thought, while it seemed simple when I first cooked it up, is looking like it's growing in complexity. Whatever we do, we should try to find some minimal useful subset and implement that and avoid the temptation of going for the cure-all from the start.