Views: Rewrite field, strips some HTML tags (SOLUTION/WORKAROUND FOUND FOR STYLE TAG)

The central problem is that you can both execute JS with style="" and object.

I don't think this should be used. If you need custom css use css and not inline styles.

  /**
   * Render this field as altered text, from a fieldset set by the user.
   */
  function render_altered($alter, $tokens) {
    // Filter this right away as our substitutions are already sanitized.
    $value = filter_xss_admin($alter['text']);
    $value = strtr($value, $tokens);

    return $value;
  }

It uses filter_xss_admin to produce safe html. As i said you cannot use object because you can embed js there, the same as style.

If you don't want to use real css, have fun :)

Because it's user input and as a security measure we make sure user input has at least minimal sanitization. It's more or less Drupal policy that we should do this.

The only alternative is using a template which will not be filtered.

I agree with iantresman here on all points. I tried to implement http://drupal.org/node/118343#comment-1442786 and wondered why nearly everything got striped out.

It should not or at least a big more openly check for xss.

Edit : Just a note to myself

views/handlers/views_handler_field.inc

  function render_altered($alter, $tokens) {
    // Filter this right away as our substitutions are already sanitized.
    $value = filter_xss_admin($alter['text']);
    $value = strtr($value, $tokens);

    return $value;
  }

to

function render_altered($alter, $tokens) {
    $value = strtr($alter['text'], $tokens);

    return $value;
  }

removes the xss protection.

That's exactly the problem. You can't be sure about the output unless you don't filter out stuff.

If you wish to use inline styles for your solution, you could use something like the contemplate.module or modify your node-[content type].tpl.php file to produce the results you want.

I am going to close this ticket as the fundamental request is to change how Drupal protects itself against potential exploit and the request here does have alternative solutions outside of the functionality of CCK and Views.

I'm having the same issue trying to add css for views slideshow.

In the tutorial (http://mustardseedmedia.com/podcast/episode42) the guy adds two divs but they get stripped out in my views.

As far as a "security measure" shouldn't that be up to me? :)

I agree with iantresman here on all points. I

'object' tags and 'style' keywords do not qualify as 'nearly everything'. The XSS filter is actually quite permissive.

As far as a "security measure" shouldn't that be up to me? :)

The security policy is set by the Drupal project itself and the security team. I am just following the policy, and no amount of pushing me is going to get Views to change on this. You should still be able to set classes in your divs, but you can't embed inline styles. (Besides, inline styles are a bad idea in any case).

I need to use inline stylesheets so that my pages can be emailed as an HTML newsletter that will be interpreted correctly by various email clients.

The funny thing is that Panels has no problem letting me add <span style=".."> but Views will strip it out. Unfortunately I am not getting the level of control within Panels to allow me style these pages without also using Views.

When creating node content I have the choice of which input filter to apply , should I not have that same option while creating content in Views?

Also @Xian re post#7... are you saying that if I edit "views/handlers/views_handler_field.inc" I will be able to get views to print my inline stylesheets?
,,, My only concern there is that when I upgrade Views I will again lose that inline ability.

Seriously. You can use templates. It's not that hard.

It's certainly better than hacking the module.

I don't understand why you're arguing with me.

The security team will file security issues if I do not use filter_xss_admin(). No argument you can give me is worth that. The only way not to do that would be to add fields to set a filter format and let you select the filter formats so that it can be permission based. Not doing that.

You'll just have to cope. This argument is done.

This has just caught me out too. I was trying to user option in a rewritten field.

I feel that in the very least the users should be alerted to the fact that views is stripping out some of their text, or change the help text:

The text to display for this field. You may include HTML...

is a little confusing, I assumed that it was full html.

I feel like a point is being ignored or missed here...

It would make perfect sense to strip HTML from the replacement patterns ultimately coming from user input, but not the administrative entered rewritten output. Using HTML in the rewrite field is great for an even more rapid development when a view template might not be necessary. Rapid development is why we love Drupal and views so much in the first place, and as long as the HTML is coming from the rewrite field in views and NOT the replacement pattern I don't see a security issue!?

I also just wanna say thanks to everyone involved in views for help in making Drupal what it is today!

Regarding putting DIV's in my field rewrites - I am not mad that it's gone; but I am sad :( But MerlinOfChaos has done so much for this community that he could tell me to type with my toes and I'd try to follow his suggestions.

I tried the global custom field in D7 to no avail, so I installed the View PHP module and it mostly worked. A little counter-intuitive, since I really didn't need to use any PHP; but it got me almost back to where I was in D6. The div's and inline styles work again, but I haven't yet discovered how to put properly-formatted images within a div to do things like floating/centering them (without having to dive into the CSS and create a bunch of new classes...) Still tinkering.

Subscribing

subscribing.

Anyone know any good tutorials for creating a template for a specific field, so that style"" can be included. I'm not certain which tpl I should duplicate or where to put the replacement tpl (presumably in my themes tpl folder?).

I've got a slideshow in Views, which is running through Panels (custom front page), and want to output style="background-image:url([image-path])". This is so that I can keep the image central in different sized browsers (a pure CSS approach is proving impossible).

Strange that Views wont handle style="". Views UI access is often not granted to users. Super users that do have Views UI access could most likely cause more damage elsewhere...

Edit: Todd Young : Can style="" somehow be achieved with Views php??

Though I don't really want to reopen this issue myself, I think it's worth considering. In particular, regarding this comment:

The security team will file security issues if I do not use filter_xss_admin(). No argument you can give me is worth that. The only way not to do that would be to add fields to set a filter format and let you select the filter formats so that it can be permission based. Not doing that.

I'm curious what the rationale is behind not wanting to add that? It seems to me like using text formats would be a proper solution to this issue. In Drupal 7 adding a text format to a form is also a lot easier than Drupal 6... :)

Also, since "administer views" is listed at http://drupal.org/security-advisory-policy, and I assume (but haven't checked) that that's the only permission that allows you to edit this field, I don't think it would actually be a formal security issue if filter_xss_admin() were simply removed. (Of course, that doesn't mean it's a good idea to simply remove it; I agree it's definitely not.)

With all respect to dereine and views team, how you guys apply background image to field B with pure CSS if actual imagecached url comes from field A?

I suppose I know how to rule my content if I have enough permissions to access field settings. As far as I can see everybody's agree with this point. So what's the use of making things even more complicated with restrictions like this one?!

Thanks in advance.

Argh, Don't change statuses if you don't know what they mean. Seriously. There's a link and everything.

And no, I am not changing this. If the filter_xss_admin() filters too much, then use a template. I realize it's inconvenient. I am not changing it.

SIMPLE WORKAROUND FOR ADDING STYLES TO VIEW FIELDS WITHOUT MODIFYING THEME CSS FILES

While I do not agree with anyone who says it poses a security risk or goes against the Drupal policy, I do understand the difficulties authors and maintainers go through to keep their modules Drupal approved.

In Drupal there are many ways to accomplish things, so I considered other crazy ways of accomplishing this task. One of them which seems to work great is outlined below.

1. Create a Block and set the input filter to Full HTML.

2. Insert your css code in between the style tag. If you are using a wysiwyg editor make sure you place this code as source.

e.g.

<style type="text/css">
.mydivclassname {
	background-color: #FC0;
	width: 45px;
	height: 20px;
	text-align: center;
	margin: 0px;
	padding: 3px;
}
</style>

3. Set this block to be placed somewhere above your content, also setting the block to be ONLY displayed on your page where your view is located.

4. Rewrite your view field as per example below and voila' :)

e.g. <div class="mydivclassname">My Text</div>

A brilliantly creative tip, but isn't it just as quick and easy to write a field template file :) That'll keep your CSS separate, where it belongs.

Very creative workaround though :)

Here is a reason to use inline styles.

I have a color field (several actually) that I have as part of my CCK "Event" definition so that each Event can have a unique set of colors. I want to pull that color out and assign it as part of the definition of a block.

i.e. My 'Sidebar" color, a light, pale color, is the background for the block I am creating with the View.

This lets me edit the colors assigned to an event in the event editor.

But the

Kudos to XiaN Vizjereij for coming up with the best answer for those of us who know how to program but use Drupal for streamlining our work. I would not recommend this approach for anyone who does not clearly understand the security implications of doing this but they are minimal if you understand the risks of the tags you ultimately want to use here.

An open letter to the Drupal Team and Module developers

There is no question about the fact that the work that Module and the Drupal developers have done deserves admiration. However, there is a fairly consistent theme I am beginning to observe as I look through issues that get opened regarding these Drupal Modules. There is an ugly undertone of crass, rude and utter disrespectful behavior from the developers (or their agents) to users who choose to use these modules and run into issues. I have seen everything from sarcastic remarks to clear disdain for the user who would dare to ask that something be fixed or considered as an add-on to a module that may deserve it.

I understand that not every question deserves the attention and time of the Module Developer. However, I think the time has come to demand that when Module Developers do respond, all of the Drupal community should be treated with the same respect and simple courtesy that anyone would expect when buying a product or using a service.

Anyone who would think that since “I have devoted my time for free” therefore, “everyone else is beneath me, stupid or not deserving” of a clear, concise and respectful response; has lost the notion of what the spirit of an open source community truly means. It is collaborative, critical, notional, forward-leaning and sometimes unpopular.

To the Module Developers; if you don’t like dealing with your CUSTOMERS or are overworked and cant then, hire someone with better communication skills who can. To the Drupal Team; please remove “Won’t Fix” from the community’s vocabulary. It’s not productive or positive. Surely someone Will Fix and will be happy to for free in most cases. Module Developers should be responsive and courteous to their CUSTOMERS or banned from responding. I would like to propose a rating system for Module Developers and their issue responses. Their peers and users should be allowed to rate their support for their product; especially, when we contribute to the fix. If the developer has been absent or obstinate to a community concern with their module then they should be rewarded with the community’s opinion about that action.

Again, I don’t want anyone to misinterpret my sincere admiration for the hard work everyone does in making Drupal an excellent tool in this open letter. However, the time has come to make the experience beyond the tool a better one.

Just my 2 cents.

Why is this closed,wont fix?
Is it so hard to add text format selection? :S

Since header and footer has it,rewrite output textarea should have it too....

I am sure adding this wouldn't be a security risk/threat.

I humbly disagree with the won't fix status and cant understand module's maintainers reaction.

If you make a custom text input format that does no filtering (no doubt you already have), then you can use this in the Header/Footer section of the Views UI and insert a script tag. Use your fields to put your desired attribute in a hidden result, and in the unfiltered Header write a script to move it with jQuery.

<script>
window.$ = window.jQuery;
$(function(){
  $('.views-row').each(function(n, el){
    // use the resulting element as our search context 
    //  by passing as second arg to jQuery
    var attr = $('div.my-attribute', el).first().html();
    $('a.my-target', el).attr('href', attr);
  });
});
</script>

Alternatively, XiaN's fix above is a good one, but as others have said, can be broken by updates.

Agree that this policy is not an effective security measure. "Won't fix" != "not broken".

+1 to reopen this issue, since skipping filter_xss_admin for administrators does not in fact mean breaking security policy.

Apologies, didn't realise was altering page title. Old title reinstated.

I am not trying to add css, but I am trying to rewrite the results of a field to include an img tag.
The first part of the tag then gets stripped, the second part stays:

In rewrite:

<img src="http://example.com/imgfile=[replacementfield]" alt="Image">

The result is:

thefieldcontent" alt="Image">

My workaround: Insert the img tag into a field for that content type. A bit annoying, because I'll have to re-import 25,000 nodes.

Is there anything else that I overlooked?

Ursula

(sorry that I post this on a closed threat, however, the issue title fits so well)

I actually just put the style code in the views header and used token replacement from one of my field values to output a color. In this case my field is a jquery colorpicker field and i'm outputting the field's css value rather than the color bar.

<style type="text/css">
.coupon-bg {
background-color: [field_coupon_bg_color];
}
</style>

Then i assigned my class to the views row and it works magnificently. I agree, using an external stylesheet or field templates would be the "correct" way perhaps but for dynamic coupon styles... this is a wonderful little hacky way of doing what i needed it to. Additionally, my colorpicker field is configured as a user profile field which allows the user to pick predetermined color schemes for all the content he/she edits. Pretty cool i think anyway...

need to set <div style="background:[field_logo] center center no-repeat" class="customer_logo"></div> this is the only way to vertically center images ! :(

This is quite an unbelievable turn around to tell a developer and admin that they are not trusted to enter code. We are not the user, we are the administrators. We can determine what code is both safe and "better".

In my specific case I am entering a div style width that is specific to the image content in the view. This is a very simple bit of logic gathered from the replacement pattern. It would change depending on the image. Why should I go about doing this dynamic style definition in such a convoluted outside manner when I have the information right at hand in the rewrite area? Because Drupal wants to protect me from myself and prevent me from entering bad code? I can wipe my entire server at the root if I want to, I don't need Drupal "protecting me". What the heck is going on here with this attitude?

This is 100% true. Dynamic background images used in responsive containers could be a breeze with inline style="". Otherwise I will have to create a module or get jiggy with jquery.

Thank you very much for this suggestion. It solved my problem of applying text-transform to a field in a view.

@41

This is just how chaos is. He is very stubborn and rarely admits when he is wrong. While this problem is easily solved using the standard drupal filters policy, he continues to ignore it simply because he can and theres nothing you or anyone else can do about it. It's called a power trip, and he is known to have many of them. For the most part, he usually gets things right. But when he's wrong, prepare for a hurricane of insults because he'll go out of his way to cut off his finger to spite his nose. I particularly linked the 'link' comment. A rather humorous insult, but again, par for the course.

The only real work around method for this is to use a template or use Views PHP (successor to Views Custom Field mentioned above) to produce the output since it's not filtered but then you lose the ability to use tokens which is a bummer. But all of the tokens are still available, they are just a little more convoluted to access than a simple token. 80% of the time, using a template or views php field to enter a little HTML such as a checkbox around some output is completely unnecessary and total over kill, but what can you do when you're using something you have no control over. Personally when I add HTML to any field, I will almost always use Views PHP instead of the template suggestion that is suggested so much around here. A template is just to much of an overkill for 1 or 2 fields.

Changed to works as designed since this isnt a bug and doesnt require fixing, thus no need for 'wont fix'.

For those looking for a super easy method to get around this using views_php. Install the module, clear your views cache so that the UI is rebuilt. Go to Fields area like you would normally and add a new field called "Global: PHP". Then go down to the text area that says "Output Code". This is essentially an unfiltered version of the "Rewrite" field that has been discussed here. Simply use raw HTML like you would have tried to do with the Rewrite field and there you have it. You can also use tokens using PHP variables. Click the "Available Variables" to see what they are just like you would do with tokens. This also has the added benefit of being able to use <? tags for PHP as well, but who needs that when all you want is a quicky HTML output with some tokens :)

Here is an example of what you can put in that output text area. Notice how very close it is to the Rewrite field. The main difference is that the tokens are a little more lengthy to type (convoluted) but it works great. Very easy, 50x faster than making a template or any other option suggested I think.

<input type='checkbox' name='nids' value=<?php echo $row->nid; ?>> Something about the checkbox here <?php echo $row->title; ?>

I wanted to print a flash file that was uploaded in a node, but since embed and object was stripped, I had to do it this way:

1. I set up a view with a field to only print the URL of the flash file.
2. THen I created a views template for that specific field.
3. In that template file i added the needed HTML and printed the output - which is the flash files path - as src.
4. Done!

I can't get views_php to not strip the tags in D7. Am I missing something?

Thanks!

Hi All,
Same kind of sicha here, I am wanting to dynamically declare the colors. It is for a high school football team with over 400 possible opponents. I have the "Team" content type for possible opponents set to accept a primary color #990000 and secondary color #0000 as examples... so when the team names are printed out on the page (like in a schedule or whatnot) the opposing team names are in their respective colors.

What I am trying to do...
Ex: <h2><span style="color:#990000">Kentlake</span> <span style="color:#000000">Falcons</span></h2>

It pretty much needs to be dynamic.

Glad I found this I thought I was losing my mind with that views field rewrite output stripping it out.

Thanks!
~ Jim

+1 for fixing this (probably not going to happen). Pity that the Open Source development process sometimes fails.

This seems silly!

Not come across something like this on Drupal before. I've just spent a large amount of time working out why on earth my inline styles weren't working, and this at the end of a body of work, not suspecting I would not be able to add inline styles in views. Like other users here its something I need to do, not really a choice, but even if it were a choice, let me choose!. To not be able to add this in views, especially for the spurious "security" measure given is bizarre, and why it remains when users have argued sensibly for it to be changed is not helpful. User content would clearly already be filtered out at an earlier stage as with all other user input, and there are plenty of other places in views where we can enter inline code. Sure, you're not obliged to do anything, but to suggest there is a security issue as the barrier doesn't seem correct, to me, as well as to others. This is the admin side of things! Let us do the stuff we need to do!

Inline styles are also useful and essential in some circumstances. Earlier in this thread someone said "If you don't want to use real css, have fun :)"...hmmm, try compiling and sending emails without inline styles and see how you get on!... Exactly as another user here I am creating a newsletter via views to be emailed. Gmail, for one, and one of the worlds largest email providers, only supports inline styles. Using something like; div class="mydivclassname" is useless, it will fail. So for an everyday global instance, the one I happen to need it for, you can see how important being able to produce inline styles might be, and how unhelpful this annoyance is.

will have a look at views php to see if that can help. Though it looks like altering views/handlers/views_handler_field.inc might be the quicker yet ugly solution.

(update/note to self! #7 worked out well, thanks Xian)

 Pity that the Open Source development process sometimes fails.

Ah right this would be really better with proprietary software, they would lick your feets to serve you.
Please realize that this is open source software you get for free, you kind of have to accept if the maintainer says that he doesn't consider to change the behavior.

No additional feeding the trolls, sorry.

I am temporarily re-enabling comments just to add:

Several people have commented that it should be easy to just add the standard filtering mechanisms.

However, these people are mistaken about how easy this is.

Yes, it is easy to implement, but it comes with 2 problems:

1) Filters don't export well because they use numeric IDs.
2) Filters mostly have auto paragraphs turned on, which means you always need access to a generally insecure filter to prevent it from adding a <P> tag around every piece of text. Adding this midstream would be very difficult.
3) Adding this mid-stream would suddenly apply unexpected filters to a LOT of text, which would break people's sites.

The reason we want you to use the views PHP field module is so that you understand very clearly that you're doing something potentially insecure. The Drupal security team approves of this behavior. I understand that it is inconvenient. I promise, I'm not doing this to be a stubborn git -- but because we feel it is important that people understand that these tags are not secure in the hands of normal users. Inconvenience is often a price of security, and I apologize to people who think that this is done maliciously or simply for the sake of being difficult.

a simple and helpful compromise

Just wasted most of a day thinking this was a filter at my end. Now I find out it's core. The OP's modification to Drupal should be used: Drupal Views text should be changed from:

The text to display for this field. You may include HTML. You may enter data from this view as per the "Replacement patterns" below.
to:
The text to display for this field. You may include limited HTML. Style and Object tags will be stripped. You may enter data from this view as per the "Replacement patterns" below.

Another possible solution: Only tokens are vital here since all other styles can be done in CSS. But tokens are needed for dynamic styling based on fields. Allow a section to allow Styles for tokens only.

It's really crappy to inform a site admin they are using HTML and then filter it without mention. How many thousands of dev hours have been wasted troubleshooting this over the years?

I also need to use tokens in styles to get a background image. Style="background-image:url([image-path])" is stripped. The solution at https://drupal.org/comment/5370182#comment-5370182 no longer seems to work as the Views Header strips out my style request (or else it doesn't work in blocks at all). I don't understand PHP or templates and really don't want to hack a copy of the core just to perform a simple background style.

@slamorte
My original solution still works just fine. You need to use the header type of: Global Text Area and select an input filter where html tags aren't limited so on mine, i'm not limiting any html tags in the full html text format. Then just put your code in between the style tags. You can test simply by setting a class on one of your fields of "test". And in the header for example:

It does accept tokens as well so if you are wanting to do a background image from a field, just ensure you setup the field output to get desired result.

There is no reason to hide header as all you should have in there is whats between the

tags so as long as your input filter doesn't strip that out… you are good to go.

Huh. Can't edit my comment above. Apmsooner is correct and his method is indeed working. The tokens can be added to style classes, and the classes added to the rewrite. Very clean workaround.

Is there any custom handler available that works like views_handler_field_custom but gives you an option to use an input format filter?

I need to insert bootstrap data toggle and buttons into a custom field but xss_admin strip these tags

using views_php module works but there is no token support, if you enable a patch to support tokens then the xss_admin kicks in, making it useless in my case.

only solution I now have is to hack views to remove the xss_admin render in views_handler_field.inc

how can I get away from this sanitizing, just a clean text area that accepts all markup

Prehaps instead of removing the xss filter all together as sugested in #7 it could be changed for filter_xss with a list of allowed tags, this list could be a configuration for views or gathered from a input filter.

  function render_altered($alter, $tokens) {
    // Filter this right away as our substitutions are already sanitized.
    $value = filter_xss_admin($alter['text']);
    $value = strtr($value, $tokens);
    return $value;
  }

Changing to something like this:

function render_altered($alter, $tokens) {
    // Filter this right away as our substitutions are already sanitized.
    $allowedtags = variable_get('views_rewrite_output_allowed_tags');
    $value = filter_xss($alter['text'], $allowedtags);
    $value = strtr($value, $tokens);
    return $value;
  }