CCK per field CRUD settings, caching complexity
Hello list, I am developing some per-field CCK permissions: CRUD settings for every chunk of data. But I am still rather concerned about caching. Let us assume two roles, and three field types: Role1: child Role2: easter bunnies Field1: description, viewable by boh roles Field2: Egg color: only viewable by children Field3 Egg Location: only viewable by easter bunnies IF we add an Egg Node, we will have three virtual nodes: in DB, viewed by admins etc: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. color: Yellow and white. location: Bar. child looking at node: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. color: Yellow and white. bunny looking at node: descr: This Grand Foo Egg is very nice, it tastes like beer, but is made from specially, handselected Foo. location: Bar. So back to caching: Should we cache them as three separate nodes? This means that any combination of fields and roles will get a cache entry. with five roles and 3 fields this becomes (I forgot the math, was it 5! or 5^5 ?) a lot! The other option is to cache per role: the obvious problem occurring here is what to do with users that have more then one role. In the first example each combination of roles has an own entry. But here we would have less cahce, but more complex code to merge the various cache results, which is additional overhead, and kindof defeats the purpose of cache. So: Are there other ideas? Modules I should look at? Or do you think I am going down the wrong road? Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek
On 27 May 2006, at 1:02 PM, Bèr Kessels wrote:
So: Are there other ideas? Modules I should look at? Or do you think I am going down the wrong road?
i think the object should always be completely cached (ie: one cache per node) but the node load access mechanism should trim what you don't have the right to see. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op zaterdag 27 mei 2006 21:42, schreef Adrian Rossouw:
i think the object should always be completely cached (ie: one cache per node) but the node load access mechanism should trim what you don't have the right to see.
Sounds like a plan. But this defeats the whole point of caching..... But I will certainly investigate this route. Another concept Ive been looking at is caching per chunk. So not caching a complete node, but only caching the parts of the node and then compile them on load. There could be a possibility to cache that compiled version too. Bèr
On 29 May 2006, at 12:15 PM, Bèr Kessels wrote:
Sounds like a plan. But this defeats the whole point of caching..... But I will certainly investigate this route. How? We cache to avoid complex joins and queries.
Another concept Ive been looking at is caching per chunk. So not caching a complete node, but only caching the parts of the node and then compile them on load. There could be a possibility to cache that compiled version too.
Many queries. versus a single query. A single for loop which just blanks out the fields you don't have the right to access, and a simple form_alter to hide just the fields you aren't allowed to see. versus an entire system to select only those fields, and caching alternate versions of the node based on arbitrary parameters (roles is just one way to split it, a prime example is social networking, where people in your friends list have more view access to your profile). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 29 May 2006, at 12:15 PM, Bèr Kessels wrote:
Sounds like a plan. But this defeats the whole point of caching..... But I will certainly investigate this route. How? We cache to avoid complex joins and queries.
Another concept Ive been looking at is caching per chunk. So not caching a complete node, but only caching the parts of the node and then compile them on load. There could be a possibility to cache that compiled version too.
Many queries. versus a single query.
A single for loop which just blanks out the fields you don't have the right to access,
That means you will have to include the "who may see what" info in the cached data, is that your intention? Also, when I first proposed caching of the node object, there were arguments that you would lose the possibility to individualize the node like for example the poll module does. The same would apply here. My proposed solution was to move individualization to the _view hook, but was not well received. Cheers, Gerhard
Op maandag 29 mei 2006 12:32, schreef Adrian Rossouw:
(roles is just one way to split it, a prime example is social networking, where people in your friends list have more view access to your profile).
This is, in fact, the main reason why I need this code :) However, removing stuff by permission is *always* the wrong way around. It is opt-out security, which is close to "not security". If someone is not allowed to not see something, it should not even be considered loading. It should not be available. Anywhere. What you propose is indeed the fastest and simplest road to what I need. But it is also opt-out security. Wich is ALWAYS a bad decision. It WILL result in fields showing up where they should not (vs: fields do NOT show up where they should), this is murpys law, but one that should definately be taken into account zhen developing something. And security: having something show up by accident may not seem like a big deal to any of you. But imagine upgrading some (bad coded contrib) module and then to find out that you've had your customers creditcard details open to the world for a few days? Such things happen. They happen when you use opt-out security. The bad-coded module should be coded better, sure. But it should not have received the data in the first place. Still, as it is, the other alternative is bad, or no caching. Ill have to choose one of two bads. Bèr
On 29 May 2006, at 2:18 PM, Bèr Kessels wrote:
However, removing stuff by permission is *always* the wrong way around. It is opt-out security, which is close to "not security". If someone is not allowed to not see something, it should not even be considered loading. It should not be available. Anywhere.
If someone has access to enough of the code to be able to trick node_load into not trimming the fields, they have enough access to get the stuff directly out of the database, and you have far far more of a problem than you thought. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 5/29/06, Bèr Kessels <ber@webschuur.com> wrote:
However, removing stuff by permission is *always* the wrong way around. It is opt-out security, which is close to "not security". If someone is not allowed to not see something, it should not even be considered loading. It should not be available. Anywhere.
What about if modules (or even themes) need to "see" certain values, for some kind of conditional logic, but the users aren't allowed to access them? In this case, your security model either can't be implemented, or would have to be hacked around; and "opt-out security" would be a better option. I've always found that loading all fields into an object is best, since you never know when you'll need some of them. But then again, I've never had to deal with field-level access control. Cheers, Jaza.
Op dinsdag 30 mei 2006 01:24, schreef Jeremy Epstein:
What about if modules (or even themes) need to "see" certain values, for some kind of conditional logic, but the users aren't allowed to access them? In this case, your security model either can't be implemented, or would have to be hacked around; and "opt-out security" would be a better option.
Nothing, absolutely nothing, should hold a module from loading data. If possible there should be proper apis for all that. But if they do so, they ACTIVELY go out and collect that data, thus knowing how ot handle it. This is not the same as modules accidently showing something because they forgot to call a certain filter/hook/etc. Forgetting something is done very easily. and if your security model is built on top of "hoping that loads of people are not forgetting stuff", you have a very bad security model. Bèr
On 30 May 2006, at 10:21 AM, Bèr Kessels wrote:
This is not the same as modules accidently showing something because they forgot to call a certain filter/hook/etc. Forgetting something is done very easily. and if your security model is built on top of "hoping that loads of people are not forgetting stuff", you have a very bad security model. Umm. unless you intend on building this into the base cck, your own module is the only thing that needs to remember anything. If you don't have the field permissions module enabled, there will be no field level permissions. period.
I don't believe crud for all fields should be a base feature of cck. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Bèr Kessels wrote:
Op zaterdag 27 mei 2006 21:42, schreef Adrian Rossouw:
i think the object should always be completely cached (ie: one cache per node) but the node load access mechanism should trim what you don't have the right to see.
Sounds like a plan. But this defeats the whole point of caching..... But I will certainly investigate this route.
Another concept Ive been looking at is caching per chunk. So not caching a complete node, but only caching the parts of the node and then compile them on load. There could be a possibility to cache that compiled version too.
At the risk of making a number of people vomit, I could point out that this is the sort of thing which Smarty [1] is exceptionally good at already, what with its ability to cache areas within pages, and its support for per-user cache versions [2]. If you need to cache the hell out of everything, the additional processing added by the Smarty class would definitely be outweighed by the cache benefits. Plus it can live at the theme level. Site admins would have to be very careful to disable Drupal's own caching, though. jh [1] But not the current Drupal Smarty theme engine, I have to add. [2] By inference. It can switch based on arbitrary theme-set criteria which in our case could be $user->uid. -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
On 29 May 2006, at 12:44 PM, John Handelaar wrote:
At the risk of making a number of people vomit, I could point out that this is the sort of thing which Smarty [1] is exceptionally good at already, what with its ability to cache areas within pages, and its support for per-user cache versions [2].
I believe we are discussing object caching, and not output caching at this point. Implementing that kind of caching in phptemplate isn't that hard either. I'm just not sure where it's useful at this point, as I believe block level caching is more useful (as caching is a module developer oriented task, and not a theme designer oriented task). This was in one of chx's version of the regions patch, where each block had a 'cache' property, including a callback to check for expiration. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 29 May 2006, at 12:44 PM, John Handelaar wrote:
At the risk of making a number of people vomit, I could point out that this is the sort of thing which Smarty [1] is exceptionally good at already, what with its ability to cache areas within pages, and its support for per-user cache versions [2].
I believe we are discussing object caching, and not output caching at this point.
Yeah; actually Smarty gets us nothing at all, does it? <slaps own forehead> I would be interested in something which took Jeremy's no-DB-hit filesystem cache approach and expended from there, though. That thing's a freakin' lifesaver. Perhaps we ought to consider this not only in terms of things which can be cached per-user, but also the larger group of items which can be cached per-role... -- ------------------------------------------- John Handelaar E john@handelaar.org T +353 21 427 9033 M +353 85 748 3790 http://handelaar.org ------------------------------------------- Work in progress: http://dev.vocalvoter.com -------------------------------------------
Op maandag 29 mei 2006 13:01, schreef Adrian Rossouw:
I believe we are discussing object caching, and not output caching at this point.
More precise: We are trying to avoid certain chunks in cache. Chunks that should not be shown to them, and therefore might best not even be available! Or, more pragmatic: How to allow fields in CCK to be more dynamic, while still keeping the power/goodness of caching. My case: I want to make fields accessible by roles. Meaning "visitors can see the summary, but not the whole post. While paying members can see it all". And such examples. Bèr
participants (5)
-
Adrian Rossouw -
Bèr Kessels -
Gerhard Killesreiter -
Jeremy Epstein -
John Handelaar