When anonymous or authenticated users do not have permission to use the input filter selected for a text field, they also do not seem to have permission to see that field in a view -- the content is replaced by "n/a".

To replicate this, remove anonymous and/or authenticated users from the Filtered HTML filter. Then, as that user type, try to view some content created with the Filtered HTML filter, as rendered by the content_format function.

I've tracked the problem down to line 243 of text.module.

  if ($field['text_processing']) {
    return check_markup($text, $item['format'], is_null($node) || isset($node->in_preview));  //<=== THIS LINE
  }
  else {
    return check_plain($text);
  }

If I replace is_null($node) || isset($node->in_preview) with FALSE , the content is displayed. However, I'm guessing that removes whatever permission checking that code provides, so that probably isn't the way to go.

My current workaround (as suggested by http://drupal.org/node/232401) is to give anonymous and authenticated users access to the input filters used, but that goes counter to the whole point of input filters. Any ideas on what the proper solution would be?

Comments

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Just to note, I'm also experiencing this with a 5.x-1.10 deployment.

jesss’s picture

jesss commented
Version: 5.x-1.9 » 5.x-1.10

I've upgraded to 5.x-1.10, and am still experiencing the same issue. Anybody have any ideas?

agileware’s picture

agileware commented

From my experience this is not an issue with normal node creation and viewing, so if I create a node with full html and anonymous users can't use the full html filter they can still see the content.
If anyone is experiencing differently please say so.

The problem I am getting is only when calling cck functions from another custom module. In my case I was calling the content_format function but I was not passing through the node, which is an optional parameter.

The content_format function then calls the text_field_formatter function, which checks that it has been passed a node and if it doesn't it checks the input filter permissions.

If you send the $node variable through you should not have a problem.

So I would say this is quite possibly by design and you just have to watch out for it when calling these formatting functions.

markus_petrux’s picture

markus_petrux commented
Status: Active » Fixed

Even though the $node is optional, you should give one if and when the job that content_format() is requested to do needs it. In this case, the caller is responsible to give a node so that the formatter knows if the format access check needs to be made or not.

This is the same in CCK for D6.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Logi-1’s picture

Logi-1 commented

Hi,

I'm dealing with the same thing with php code in the field, this should be reopened.

Logi-1’s picture

Logi-1 commented
Status: Closed (fixed) » Active
markus_petrux’s picture

markus_petrux commented

@Logi: Could you please describe why do you think this needs to be re-opened?

markus_petrux’s picture

markus_petrux commented
Category: bug » support
Status: Active » Closed (fixed)

Ok, this is not a bug report but a support request. An answer has been given in comment #4.

If something in CCK is not giving the $node as context to content_format(), then please file a separate bug report. If the problem is related to another module, then please file an issue to the proper issues queue of that module. Thanks.