Adobe Campaign Standard

SonnyRD · 10/3/17

Hello--

I have a personalization field in my email template to include a URL, like this:

<%@ include file='http://www.google.com' %>

However when I run the preview, I am getting the following error:

Error while evaluating document

BAS-010014 Cannot open file '/usr/local/neolane/nl6/var/www.google.com' with read access (errno=2, No such file or directory)

JST-310008 Failed to process directives '<%@ include' (content htmlContent).

Interestingly, if I have an https link, e.g.,

<%@ include file='https://www.google.com' %>

the error message changes slightly:

Error while evaluating document

DLV-490143 Cannot open file '/www.google.com'

JST-310008 Failed to process directives '<%@ include' (content htmlContent).

Does anyone have any idea what could be wrong? It worked before in build 8795 and we just upgraded to 8883, so I'm pretty sure it's related to an update.

Thanks,

Sonny

SonnyRD · 10/9/17

Just wanted to add/document that build 8884 fixed this issue for me.

Also thanks to Jean-Serge Biron for his thoughts on urlPermission--something to keep in mind for the future!

Sonny

View solution in original post

Jean-Serge_Biro · 10/4/17

Hello SonnyRD,

Please may you explain your real goal, not the issue you cope with?

In the meanwhile, a short reminder/explanation:

An included file, whatever being a file on the server or a html file given by URL (only syntax differs but the principle is the same), must be:

a valid html code to include in your html delivery message (not only portion of html adapted in the logic of inclusion placeholder, but also compliant with email deliverability rules (no div element but table, etc etc).
But perhaps the URL resource file is the full email body content, in your case? please confirm
beeing accessible from the Adobe Campaign applicative server (not the MTA server, because inclusion is done during the preparation phase); as you can see in your own logs, it can depend on port (http/https), so check if there are firewall rules blocking your URL resource file to be acceded.

Hope this helps.

Regards.
J-Serge

SonnyRD · 10/4/17

Hi Jean-Serge--

I don't fully understand what the code does, but it looks like it's grabbing whatever is in the URL (which in this case contains the web version of a daily newsletter) and writes the full HTML code of that web page into the email template during execution.

Here is the code that's in the email template:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML>

<HEAD>

</HEAD>

<BODY>

<% document.startBuffering(); %>

<%@ include file='(sample newsletter content URL here)'%>

<%

var dte= formatDate(new Date(), "%ail, %bil %2D, %4Y");

var html = document.stopBuffering();

html = html.replace(/(\r\n|\n|\r)/gm, "");

html = html.replace(/<\$\$ RECIPIENT \$\$>/g, recipient.id);

html = html.replace('Sample Newsletter', dte);

// Get body style

var bodyTmp = /<body[^>]+style=\".*?\"/.exec(html)

var bodyStyle = /style=\".*?\"/.exec(bodyTmp)

// Get title

var title = /<title>[^<]+<\/title>/.exec(html)

// Get body

var body = html.replace(/.*<body.*?>(.+)<\/body>.*/ig, '$1');

%>

<%= title %>

(CSS here)

</STYLE>

<% document.write(body); %>

</BODY>

</HTML>

I suspect that something has changed after v6 8795 (our last build before upgrading to 8883 this week). The base URL of the link referenced in the include file has already been added by Support/TechOps to our serverConf.xml due to the enhanced security around using URLs, but we're not sure why this particular issue persists.

Thanks,

Sonny

Jean-Serge_Biro · 10/4/17

Thanks for your additional information.

I confirm, since build 8857 (July 2017), the urlPermission whitelist in serverConf.xml is mandatory for Javascript manipulation in workflows/etc for allowing URI external access.

In the serverConf.xml file, take care, urlPermission rules are defined by protocol http or https, so please duplicate lines (or do it by regex but less readable) to allow both protocols.

Eg:

allows only https protocol.

From the Javascript personalisation code you provide, I understand it is done more or less what is done by Content Manager module (of course, more simplified regex replacement placeholders data by dynamic values coming from the URL resource (probably XML data) managed a bit as a webService data feed/newsfeed , but the idea is about the same).
And I guess you don't have this Contennt Manager module in your contract; it is a pity but don't worry, it should still work anyway.

So, let's try to resolve your issue in your current situation!

To my mind, the urlPermission regex are probably too strongly defined; can you check again on your applicative server (not MTA) the urlPermission for your domain URL?

Regards
JS

SonnyRD · 10/4/17

Thanks, Jean-Serge. Yes, you are correct: we don't have Content Manager, unfortunately.

As for the urlPermission, we're actually using http only. The https test I mentioned in the original post was just a curiosity on my part, to see if it resolves anything. The base URL that I provided to Support was also http, so I wouldn't be surprised if they hard-coded only http, which is fine. That said, I've asked Support to provide the exact URL that they added to our serverConf.xml file. I'll update once I hear back.

In the meantime, do you have other thoughts as to how to fix this?

Thanks,

Sonny

Jean-Serge_Biro · 10/5/17

Hi Sonny,

Perhaps, if the regex can't be simple (if your IT service denies putting simple rule but wants to put full URL), or if anything else such as character mistype, I suggest asking them for setting debugTrace mode to true; and if not enough, temporarily they can't put "ignore" value for action attribute, so it comes back to previous situation before 8857 build (July 2017), less secure but acceptable for temporary tests, in order to check that the issue comes from urlPermission rule and not from anything else.

	<!-- List of URLs that the Javascript code can access.
	action : Default action if the URL is not in the authorized list. Values: deny (default), warn, ignore
	debugTrace : Debugging trace of the URL selection mechanism Default: false -->
	<urlPermission action="" debugTrace="false">

Regards
JS

SonnyRD · 10/5/17

Hi Jean-Serge--

As it turns out, according to Support, it's a regression of an older issue. They have now installed the hotfix in our instance and that solved the issue without having to change our code and workflow on my end.

Sonny

SonnyRD · 10/9/17

Just wanted to add/document that build 8884 fixed this issue for me.

Also thanks to Jean-Serge Biron for his thoughts on urlPermission--something to keep in mind for the future!

Sonny

Adobe Campaign Standard

Personalization field to include URL not working?

Learn

Documentation

Community

Support

Resources

Adobe account

Adobe