style attribute not being rendered

[carloso98118279]

I'm trying to add a style dynamically with HTL.

HTL code is:

<section class="header-page" data-sly-attribute.style="${header.cssStyle}" data-sly-use.header="com.acme.foo.Header"> </section>

And in my Java class I have:

public class Header extends WCMUsePojo { private String imagePath; @Override public void activate() throws Exception { ValueMap properties = getProperties(); this.imagePath = properties.get("fileReference", ""); } public String getCssStyle() { return imagePath.isEmpty() ? "" : String.format("background-image: url('%s')", imagePath); } }

But it's not being rendered, even when imagePath gets a valid value. I also tried using contexts, but nothing seems to be working.

Any ideas as what might be the problem?

Thanks

[Peter_Puzanovs]

Hi Carloso,

1) Create getter for cssClass variable, then, it will be shown.

2) Consider using SlingModels, instead of WCMUse, it will promote cleaner code and better system in general.

Regards,

Peter

[carloso98118279 · Accepted solution]

Thanks PuzanovsP!

Unfortunately it was my mistake when trying to put the code here, but in my code the method exists so the error is elsewhere. I edit my question to remove it since it's not really relevant.

What I think is happening is that HTL thinks that putting background-image: url('/some/path') in the file can be harmful, I just don't know why. So my question is still open.

Thanks for the suggestion on SlingModels it seems interesting.

[Feike_Visser1]

Specify @ context='styleString' in your component.

For style attributes you need to see this manually.

More info here: https://docs.adobe.com/docs/en/htl/docs/expression-language.html

[Feike_Visser1]

1. <section class="header-page" data-sly-attribute.style="${header.cssStyle @ context='styleString' }" data-sly-use.header="com.acme.foo.Header">
2.  
3. </section>

[carloso98118279]

Thanks Feike!

I tried all contexts but none were solving the issue. Is there a log to see why HTL thinks my css rule is harmful?

I tried to change the attribute to id just to see what might be going on:

<section class="header-page" data-sly-attribute.id="${header.cssStyle @ context='styleString'}" data-sly-use.header="com.acme.foo.Header"> <section class="header-page" data-sly-attribute.id="${header.cssStyle @ context='styleToken'}" data-sly-use.header="com.acme.foo.Header"> <section class="header-page" data-sly-attribute.id="${header.cssStyle @ context='styleComment'}" data-sly-use.header="com.acme.foo.Header"> <section class="header-page" data-sly-attribute.id="${header.cssStyle @ context='unsafe'}" data-sly-use.header="com.acme.foo.Header">

Using styleString the css rule was being weirdly escaped. Using styleToken nothing was being rendered. Using styleComment and unsafe was "working" correctly.

I then tried to not use data-sly-attribute.style but style directly and again using the previous context, the first two didn't rendered anything while styleComment and unsafe did. So this is what I'm using right now:

<section class="header-page" style="${header.cssStyle @ context='unsafe'}" data-sly-use.header="com.acme.foo.Header">

I'll not called it a solution, but for the time being at least it works.

[Feike_Visser1]

What is the attribute value you are trying to output?

[carloso98118279]

background-image: url('/path/to/image.jpg');

[Feike_Visser1]

Indeed, this is weird. I guess the XSS-api validates that this is an xss-issue.

I raised this Sling issue to who is right :-)

https://issues.apache.org/jira/browse/SLING-6490

[Feike_Visser1]

the following is working for me.

Java:

public class Style {

    public String style = "/content/dam/we-retail/en/experiences/arctic-surfing-in-lofoten/camp-fire.jpg";

}

HTL:

style="background-image: url('${ fv.style @ context='styleString'}')

[teja_k]

Hi Feike,

If we are just getting image path from Java as a string property and setting it in HTL using the way you mentioned, should we stop using  @context='unsafe' and continue with 'styleString' ?

Do you foresee any other errors/leakages through this approach?

[Feike_Visser1]

Yes indeed, you should aim to avoid 'unsafe, always.

[teja_k]

Thank you Feike!