turn off html escaping of email content?

[stephanl]

Howdy,

I am trying to embed a base64 img src in the body/content of an ext-email notification, like so:

<img src='data:image/png;base64, ${FILE, path="my-base64-encoded-png.b64"}' width="900" height="550"/>

The email I receive has all '+' characters in the included base64 string escaped as &#43;.  I tried to set the email content in a pre-send groovy script, like so:

def reportPath = build.getWorkspace().child("my-base64-encoded-png.b64") 

msg.setContent("<img src='data:image/png;base64," + reportPath.readToString() + "'/>", "text/html"); 

and still see the escapes for the '+' in the email received.  I do not see an option to turn off html escaping (except for a few macro tokens, which I am not using).

Any insights/advice on how I can embed a base64 image in an email without triggeriung automatic encoding of the base64 string?  And no, referencing the image by URL is not an option, unfortunately.  Last, for grins I have included verbatim strings in the email body/content, like 'A+B' and "A+B", in all cases the '+' character arrived encoded.

TIA,

- S

[Slide]

Are you using a groovy or jelly template, or generating the HTML yourself?

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Website: http://earl-of-code.com

[stephanl]

Not using templates.  Tried using 

<img src='data:image/png;base64, ${FILE, path="my-base64-encoded-png.b64"}' width="900" height="550"/>

in the 'Default Content' section/field of the ext-email plugin.  Also tried using 

def reportPath = build.getWorkspace().child("my-base64-encoded-png.b64") 

msg.setContent("<img src='data:image/png;base64," + reportPath.readToString() + "'/>", "text/html"); 

as pre-send script (also in the ext-email plugin, Advanced section).  From what I can tell, the html encoding occurs after the default content and pre-send scripts have been processed/executed.  Which would apply to templates as well, no?

Thx, S

[Slide]

What is your content type set to in the settings?

[stephanl]

HTML (text/html).  For grins, I tried Plain Text (text/plain), in which case the base64 string was included un-escaped, but (of course) not recognized/rendered as image when the containing email was viewed.  In the configuration section of the ext-email plugin these are the only two options (text/html and text/plain).  If another content-type is required, how do I add it (UI does not show option to add addt'l content types, using latest jenkins and ext-email versions), and what should it be?

Thx, S

[Slide]

There is no capability to add a different content type. 

[stephanl]

So then, do you know if there is a way to send a base64 as-is in an email?  E.g. without being html-escaped implicitly?  Looks like some macro tokens support this, through the escapeHtml attribute.  I did not see anything in the ext-email code base suggesting there is a global option/switch, or for individual fields.  But I also did not see on cursory glance where the html escaping occurs, so is there an option somewhere else?

Thx, S

[Slide]

Can you try using a groovy template instead of just trying to generate the HTML yourself? I'm not sure why the text is being encoded like you mention. I can try and recreate if you send the file you are using and the template.

[Stephan Lips]

It reproduces without any templates.  Simply put the following in the 'Default Content' field of the ext-email configuration:

<img src='data:image/png;base64,ley2Rz+WBUus2qBS8'/>

a+b

The email received will show the above as 

<img src="data:image/png;base64,ley2Rz&#43;WBUus2qBS8">

a&#43;b

(note the &#34; in place of the '+' signs).

Thx, 

- S

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/cwLvSKlxO3I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

[Slide]

Yes, I'd like you to try and see if the issue occurs with a template.

[Stephan Lips]

Yes, the issue reproduces with a template.  Curiously, when testing the template (through the 'Email Template Testing' link in the workspace), the inserted base64 string renders correctly.  The received email, however, still sees the &#43; escapes instead of the '+' char, causing the base64 img src to not render.

The template I'm using (saved to $JENKINS_HOME/email-templates) is

<TABLE>

  <TR><TD align="right"><IMG SRC="${rooturl}static/e59dfe28/images/32x32/<%= build.result.toString() == 'SUCCESS' ? "blue.gif" : build.result.toString() == 'FAILURE' ? 'red.gif' : 'yellow.gif' %>" />

  </TD><TD valign="center"><B style="font-size: 200%;">BUILD ${build.result}</B></TD></TR>

  <TR><TD>Build URL</TD><TD><A href="${rooturl}${build.url}">${rooturl}${build.url}</A></TD></TR>

  <TR><TD>Project:</TD><TD>${project.name}</TD></TR>

  <TR><TD>Date of build:</TD><TD>${it.timestampString}</TD></TR>

  <TR><TD>Build duration:</TD><TD>${build.durationString}</TD></TR>

</TABLE>

<BR/>

<img src="data:image/png;base64,<%= build.getParent().getWorkspace().child("my-image.b64").readToString() %>" width="700" height="400">

The file 'my-image.b64' is confirmed to exist in the workspace, and contain valid base64.  The contents of the file are inserted correctly, save for the html-escaped '+' char.

So, how do I turn off html escaping of content?

Thx, S

[Slide]

I don't know of anything in the email-ext code that would escape anything like you are describing. Can you try checking the "save to workspace" checkbox in the project settings and see if the same escaping is shown in the saved off file?

[Stephan Lips]

If I check 'save to workspace' the '+' chars are not being escaped with &#43;.

FWIW, I also tried a couple different email providers (my corporate smtp server, and google), in both cases the arriving email had the '+' substituted for &#34.  Since ext-email does not have its own mail server configuration, I assume it is piggy-backing of the standard email configuration/server.  Is this substitution happening further downstream, e.g. in the regular email code?

Thx, S

[Slide]

Email-ext DOES have it's own server configuration, you just have to check "override default settings" in the global config. That would be another thing to try, overriding the default settings so that the session is created completely in email-ext.

[Stephan Lips]

Nope, does not make a difference.  I blank'd out all fields in the default email configuration, and configured the ext-email plug-in overrides.  '+' characters in email content still arrive as &#43;

Is some jenkins/ext-email dependency doing this?

Thx, S

[Slide]

Hmm, actually, it looks like the CssInliner could be doing something. It processes anything that is text/html. I had forgotten about that because I didn't write that part. There is currently not a way to turn it off.

[Stephan Lips]

Hmmm.  So I looked at the src for CssInliner.  Most interesting is that if the attribute data-inline="true" is set on an <img> node, the image is retrieved, base64-encoded, and included inline.  So I did a li'l test, where I referenced an image via URL, setting data-inline="true".  And lo and behold, the resulting base64-encoded string that arrived in my inbox had .... the '+' characters replaced with &#43; (prohibiting it from rendering)

Other than that, the only code that explicitly deals with the '+' for replacement is line 135:

String trimmedStylesheet = stylesheet.replaceAll("\n", "").replaceAll("/\\*.*?\\*/", "").replaceAll(" +", " ");

and would not apply, due to the leading space.

So looks like this issue manifests itself with use of the data-inline attribute, making that feature essentially unusable.  In general, base64-encoded strings (or '+' chars anywhere in the email content) do not work with ext-email.

So where/how do we go from here? ;)

Thx, S

[Slide]

File an issue and I'll get to it when I can.

[Stephan Lips]

Done: https://issues.jenkins-ci.org/browse/JENKINS-22713

Thanks for your help/time, man!  Let me know if I can do anything to fix/resolve this.

Thx, S