Layout issue in cfdocument / any alternatives?

ML

unread,

Jun 16, 2014, 10:51:18 PM6/16/14

to ra...@googlegroups.com

Hi,

I am transitioning a ColdFusion site into Railo and one major issue we have run into is the cfdocument tag. It doesn't seem to render the layout correctly. In the simple example below: block1 and block2 should have the same width and height. But when I put in margin-left and margin-top around block2, it became smaller (the margins are subtracted from the width and height). There are other anomalies as well. I have tried inline css and that didn't work. Unfortunately this is a make or break part of the site. We can't switch to Railo if cfdocument does not work. Is there an alternative to using cfdocument that renders html correctly? Thank you.

<cfdocument format="pdf" >
<!DOCTYPE HTML>
<html>
<head>
    <meta charset="utf-8">
    <style type="text/css">
    .block1, .block2{ width:200px; height:50px; background-color: #EEE;  }
    .block1{}
    .block2{ margin-left:20px; margin-top:20px; }
    </style>
</head>
<body>
    <div class="block1">Block1</div>
    <div class="block2">Block2</div>
</body>
</html>
</cfdocument>

Adrian Lynch

unread,

Jun 17, 2014, 2:54:10 AM6/17/14

to ra...@googlegroups.com

What were you expecting it to do? Margin is outside the border, padding inside.

Here's a screenie of what I see on Railo 4.2.1.0000000000000:

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/railo/3be89939-cf25-40a7-807a-26059565a5ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ML

unread,

Jun 17, 2014, 3:29:47 AM6/17/14

to ra...@googlegroups.com

I was expecting the two blocks to have the same height and width. The way browsers would show them. http://jsfiddle.net/PYWy9/

The other issue is that block1 spans across the width of the page and ignores the width we set.

Judith Barnett

unread,

Jun 17, 2014, 4:29:01 AM6/17/14

to ra...@googlegroups.com

Here is what I see. So pretty clearly not the same.

CF9

Railo:

Nando Breiter

unread,

Jun 17, 2014, 6:54:52 AM6/17/14

to ra...@googlegroups.com

I've done some experiments varying the css, changing the units from px to cm for instance. I also moved the cfdocument tag to encompass only the div tags to refine the test case, and included attributes defining the size of the page. I can't seem to control the size of the how those divs render in Railo using similar CSS. The blocks always expand to fill the page, restricted only by the margin settings, and seem to ignore width and height settings.

.block1, .block2{ width: 10cm; height: 10cm; background-color: #EEE; }

.block2{ margin-left: 1cm; margin-top: 1cm; }

</style>

</cfdocument>

I'd argue that CSS to output to a PDF should be defined in cm, mm or inches. Defining these widths in pixels will mean that some conversion needs to take place when rendering a PDF to a physical size. That said, Railo still seems to ignore any unit, and in my tests so far, ACF seems to inflate the dimensions when set to physical units. block1 above prints out to 12.3 cm x 12.3 cm in my test on ACF 10. :-(

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CACtg%3DU%2Bazg8%3Daq1RKz6ZX46JiLw_FH3t7K66e8mRd%3DvG0Jfgpg%40mail.gmail.com.

Paul Klinkenberg

unread,

Jun 17, 2014, 3:54:46 PM6/17/14

to ra...@googlegroups.com

Hi Nando,

You should set an explicit width to the html & body tags, like so:

html, body { width: 19cm; padding:0; margin: 0; }/* or a different margin/padding if you want */

.block1, .block2{ ......

</style>

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

Op 17 jun. 2014, om 12:54 heeft Nando Breiter <na...@aria-media.com> het volgende geschreven:

I've done some experiments varying the css, changing the units from px to cm for instance. I also moved the cfdocument tag to encompass only the div tags to refine the test case, and included attributes defining the size of the page. I can't seem to control the size of the how those divs render in Railo using similar CSS. The blocks always expand to fill the page, restricted only by the margin settings, and seem to ignore width and height settings.

.block1, .block2{ width: 10cm; height: 10cm; background-color: #EEE; }

.block2{ margin-left: 1cm; margin-top: 1cm; }

</style>

</cfdocument>

I'd argue that CSS to output to a PDF should be defined in cm, mm or inches. Defining these widths in pixels will mean that some conversion needs to take place when rendering a PDF to a physical size. That said, Railo still seems to ignore any unit, and in my tests so far, ACF seems to inflate the dimensions when set to physical units. block1 above prints out to 12.3 cm x 12.3 cm in my test on ACF 10. :-(

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

On Tue, Jun 17, 2014 at 10:28 AM, Judith Barnett <jmba...@gmail.com> wrote:

Here is what I see. So pretty clearly not the same.
CF9

<cfdocbug_cf9.jpg>

Railo:
<cfdocbug_railo.jpg>

On Tue, Jun 17, 2014 at 3:29 AM, ML <min....@gmail.com> wrote:

I was expecting the two blocks to have the same height and width. The way browsers would show them. http://jsfiddle.net/PYWy9/

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CACtg%3DU%2Bazg8%3Daq1RKz6ZX46JiLw_FH3t7K66e8mRd%3DvG0Jfgpg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CAGHrs%3D8idLjskNW%2Bs9J6yv-rT4zrye%2BBFQsmph1CK88qBzrQfA%40mail.gmail.com.

idtDev01

unread,

Jun 18, 2014, 1:16:46 PM6/18/14

to ra...@googlegroups.com

You might want to take a look at http://wkhtmltopdf.org/

Nando Breiter

unread,

Jun 18, 2014, 2:19:00 PM6/18/14

to ra...@googlegroups.com

Hi Paul,

Your suggestion seemed reasonable, but it's not working for me.

<html>

<head>

html, body { width: 210mm; height: 297mm; padding:0; margin: 0; }

.block1{ width: 80mm; height: 80mm; margin: 0; padding: 0; background-color: #EEE; }

.block2{ width: 80mm; height: 80mm; margin-left: 10mm; margin-top: 10mm; background-color: #EEE; }

</style>

</head>

<body>

</body>

</html>

</cfdocument>

On Railo, the above renders block1 184mm x 184mm, but with a left and right margin of 13mm and a top margin of 17mm. Again, it seems to have expanded to a default margin and ignored the width and height settings in the css.

block2 has a left margin, compared to block1, of about 22mm.

On ACF 10, the printed blocks from the above code now measure 67mm square, the page has a left margin of about 17mm and a top margin of 24mm, and the top and right margins on block2 are about 8mm.

For a large project I'm working on, I need to develop invoices that need to be output to PDF, and alignments need to be very accurate, particularly when we print out the payment slips. That's why I got involved in this thread.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/55AED4A8-DA7E-43E9-9549-040B25022FC0%40ongevraagdadvies.nl.

Paul Klinkenberg

unread,

Jun 18, 2014, 3:09:16 PM6/18/14

to ra...@googlegroups.com

Hi Nando,

You also need something which stretches the complete page, like a div element:

<html>

<head>

html, body { width: 210mm; height: 297mm; padding:0; margin: 0; }

.block1{ width: 80mm; height: 30mm; margin: 0; padding: 0; background-color: #EEE; }

.block2{ width: 80mm; height: 30mm; margin-left: 10mm; margin-top: 10mm; background-color: #EEE; }

.block3{ width: 80mm; height: 30mm; position: relative; left: 10mm; margin-top: 10mm; background-color: #EEE; }

</style>

</head>

<body>

<div>tadaa</div>

</body>

</html>

</cfdocument>

Kind regards,

Paul Klinkenberg
www.railodeveloper.com

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CAGHrs%3D9zkE_B7S2qQxT8j%3D-BGvfZHod%2BZb-daMuqHAeqUy3Umg%40mail.gmail.com.

Nando Breiter

unread,

Jun 18, 2014, 3:32:54 PM6/18/14

to ra...@googlegroups.com

Paul,

That almost nailed it. Here's my variation, with realistic margins so the printer doesn't munge the dimensions, with the PDF it generates attached. What I see in Railo is that block2 measures 70mm x 70mm. The margins seem to be subtracted from the overall dimensions, incorrectly. block1 and block3 are the correct dimensions on the page, and correctly positioned.

There seem to be a few bugs in here, but at least it becomes somewhat manageable. ACF doesn't need a div to expand the layout, and it gets the combination of margins and widths right.

<html>

<head>

html, body { width:190mm; padding:0; margin: 0; background-color: #EEE; }

.block1{ width: 80mm; height: 80mm; margin: 0; padding: 0; background-color: #ddd; }

.block2{ width: 80mm; height: 80mm; margin-left: 10mm; margin-top: 10mm; background-color: #ddd; }

.block3{

position: absolute;

top: 10mm;

left: 10mm;

width: 80mm;

height: 40mm;

z-index: 2;

background-color: #aaa

}

</style>

</head>

<body>

<div>tadoom</div>

</body>

</html>

</cfdocument>

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/3A40F250-2690-4597-97E9-CE970C674879%40ongevraagdadvies.nl.

cfdoc.pdf

Paul Klinkenberg

unread,

Jun 19, 2014, 5:00:44 AM6/19/14

to ra...@googlegroups.com

Please understand that the pdf's are not created by "Railo" or "ACF", but by external libraries. Since Railo is opensource and free, it cannot use paid (Adobe?) libraries as ACF probably does.

Instead of complaining "ACF doesn't need a div" etc., just be happy we are here to help you. 2 mails ago, you could not even get it working. Now, your question is answered and fixed, not "somewhat manageable".

Regards,

Paul Klinkenberg

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/CAGHrs%3D8gVSRxmdqPoscbLXr9OZuu%3DmzBXKE_JDeTBCwCtWU_SQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

<cfdoc.pdf>

Nando Breiter

unread,

Jun 19, 2014, 5:43:34 AM6/19/14

to ra...@googlegroups.com

Paul,

First, thanks for your help. I am very appreciative that you stepped in and identified a workaround to get it closer to working correctly, namely a div to span the entire body element. Such workarounds aren't normally needed to get CSS width and height specs to perform correctly, so it really wasn't obvious. I doubt I would have come across it.

Second, developing test cases that demonstrate potential bugs isn't complaining, at least not from me. It is work that can be used to improve Railo, and that's why I bring up issues like this on the list and spend enough time on the test cases to try and clearly isolate the problem. If nobody here wants that, then I'll stop.

And to tell you the truth, I've largely given up doing this for ACF. Every time I've spent hours to days of work developing test cases for bugs and submitting a well documented bug report, it's been ignored, or marked as will not fix. Sometimes it has felt like an ACF engineering is back there going through the bugbase thinking "stop complaining and just appreciate what you've got!" WillNotFix!

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/ED52F40A-6B7C-4496-850B-B9CE1C3DB4BD%40ongevraagdadvies.nl.

Nando Breiter

unread,

Jun 19, 2014, 6:52:28 AM6/19/14

to ra...@googlegroups.com

Is it helpful if I file a bug report in the Railo bugbase for the above issues? Or is it considered an issue that the Railo team cannot do anything about, since as Paul indicated, an external library is used to generate PDFs?

Thanks,

Nando

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

Peter Boughton

unread,

Jun 19, 2014, 3:29:53 PM6/19/14

to ra...@googlegroups.com

Afaik, Railo uses the same PDF libraries as CF (iText and ICEpdf), though probably different versions.

They're not very good.

You should use something with a proper rendering engine.

Igal has already mentioned wkhtmltopdf and someone I know has used PhantomJS - both of these use qt-webkit for their rendering engine, which means you get similar (if not identical) results to what a webkit-based browser shows (making it much easier to check/tweak stuff).

http://trac.webkit.org/wiki/QtWebKit
http://wkhtmltopdf.org/
http://phantomjs.org/

It might be good if Railo could integrate these superior tools and have either an admin option or an attribute on cfdocument to switch the rendering engine used.

ML

unread,

Jun 19, 2014, 11:27:35 PM6/19/14

to ra...@googlegroups.com

Peter,

I was going to look into iText but if Railo is already using it then there may not be any point. Do you know how I can check what version of iText is used in Railo?

Thanks,

Adrian Lynch

unread,

Jun 20, 2014, 4:31:59 AM6/20/14

to ra...@googlegroups.com

dump(createObject("java", "com.lowagie.text.Document").getVersion());

Should do it.

I get:

iText 2.1.2u (by lowagie.com)

--

Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/2f436114-d9c8-4d51-a16a-856c6b72fd4e%40googlegroups.com.

ML

unread,

Jun 21, 2014, 3:29:08 AM6/21/14

to ra...@googlegroups.com

Thanks Adrian. It looks like that both CF9 and CF10 use iText 2.1.0, so I am not quite sure why cfdocument in Railo is mangled when they use a newer version. In any case, the latest version is 5.5 so we are going to try and see if that fixes the layout.

Aaron Terry

unread,

Jun 23, 2014, 12:01:35 PM6/23/14

to ra...@googlegroups.com

ML,

My team is going through the same process as you. Migrating from ACF -> Railo and dealing with CFDOCUMENT issues.

One major point to keep you from going down the wrong trail.

Railo doesn't use iText for HTML->PDF generation.

It uses PD4ML. You can verify this by opening up one of your Railo generated PDFs in Acrobat at looking at the document properties. I just did so on our end and I see the PDF Producer listed as PD4ML HTML to PDF Converter for Java (350b1)

I believe that I saw a few weeks ago that the HTML -> PDF functionality in iText is not opensource.

You can see the code that actually renders the PDF via PD4ml by looking at the render function (line 275) in the PDFDocument.java file in the Railo repo on Github. To see where the cfdocument tag calls this ... look at line 568 of Document.java)

PDFDocument.java (4.2 branch): Click here to see the the file on GitHub

Document.java (4.2 branch): Click here to see the the file on GitHub

Railo does use iText, but it seems that is functions of the cfpdf tag like merging, splitting, etc

I've been looking at unresolved PD4ML and CFDocument tickets in the Railo Jira project to see issues people are having and see if any workarounds are mentioned

Click here to see the list

Likewise, I've been searching for tips and tricks reading through discussion in this forum matching search terms cfdocument OR pd4ml

Click Here to see search results

Some discussions mention embedding PD4ML commands in your source to do particular things .... others mention inlining all of your CSS. Some others go into how to add additional fonts.

I'm not suggesting that you should HAVE TO look at the java source and Jira issues. Just mentioning that it may help you understand what the heck is going on when you get unexpected results.

Others have done this before, so we can too -- at least that is what I tell our team.

Obviously, we'd both prefer not to have to do all of this research to dissect the differences, but someone has to ... right?

We have a few hundred HTML -> PDF templates and I'm trying to find the most time efficient way to deal with them.

If anyone else out there has done all of this research before, please do share. If it's in the Google Group archives, I haven't found it yet -- but I am still looking.

ML

unread,

Jun 25, 2014, 5:45:23 AM6/25/14

to ra...@googlegroups.com

Aaron,

Thank you for your debrief on what you have found so far. I forked Railo wanting to look into the cfdocument tag but I got pulled into other things, so I haven't had a chance to look into it. But it looks like it's not going to be trivial to find a workaround. We have also found a few other non-trivial incompatibilities with Railo (in particular with query of queries), so I think we are not going to be able to migrate to Railo anytime soon.

Best Regards,
ML

Nando Breiter

unread,

Jun 25, 2014, 8:33:15 AM6/25/14

to ra...@googlegroups.com

I've filed a bug report that outlines my specific test cases and workarounds for this issue here: https://issues.jboss.org/browse/RAILO-3112

Hope it is helpful in some way.

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/1ecde594-64ca-45af-b9e8-967bdcc3c84d%40googlegroups.com.

Aaron Terry

unread,

Jun 25, 2014, 4:45:57 PM6/25/14

to ra...@googlegroups.com

Our team is moving forward making changes to our usage of cfdocument. We are hoping to launch within the next 6 weeks -- in the meantime we are doing our best to make code changes that run well under both CF8 and Railo 4.2.

Here is the document that I put together after digging into the cfdocument differences a few days ago. I was going to wait a while before publishing externally, but I'll go ahead and post this working copy below. If we make additions/changing, I'll repost the final version later.

General Notes:

Railo uses PD4ML for HTML->PDF conversion. As of June 2014 (Railo 4.2), the version of PD4ML is 3.50 Beta 1 -- which was released in 2009.

Familiarize yourself with the fixes mentioned in the PD4ML release notes for the many versions after 3.50 beta 1 … and realize that we don’t have access to those fixes. Consider that a list of things to avoid.

PD4ML Release Notes: http://pd4ml.com/relnotes.htm

Here is a summary of what needs to be done to make a PDF render well with Railo

PDF Body MUST be a well formed HTML document (html tags, head section, body section)
Need a cfdocumentsection tag to set the top,right,bottom,left margins to .25 (or whatever design calls for)
styles must be declared in HEAD section
convert pt fonts to pixels (used this conversion chart as basis: http://reeddesign.co.uk/test/points-pixels.html)
Document needs as least one full width block element. Just a basic <div> will do.
put this style in stylesheet: html, body { width:8in; padding:0; margin: 0; } (width should be whatever the page size is minus the left and right margins on the cfdocumentsection tag)
span tags won't render background-color and can't be floated (probably applies to other inline html elements as well). I replaced the span with a floated div & modified the div's padding and margin

Special Considerations for Headers/Footers (cfdocumentitem)

header and footer must be HTML fragments (no body tag, html tag)
styles must be inline (won’t pick up styles declared in body, won’t pick up embedded style sheet inside header/footer)
Unlike CF8, Railo doesn't need the header height calculated into the margin-top

Special Considerations for Headers/Footers (pd4ml tags)

You can use <pd4ml:page.header> or <pd4ml:page.footer> blocks instead of cfdocumentitem.

Look at inline footer option for example: http://pd4ml.com/cookbook/pdf_header_footer_generation.htm

declare the header and footer blocks BEFORE the main content -- otherwise the </html> of the well-formed body will end the document. Anything after that point will not show up
there is a hardcoded rule that the header or footer cannot exceed ⅓ of the page height.
You can use the scope attribute to assign different headers/footers to different pages
cfdocumentitem and pd4ml tags don't play well together. Not sure if there is a valid reason to do this, I was just testing the limits.

Sources:

PD4ML Cookbook - http://pd4ml.com/cookbook/index.htm
Various Railo Group Discussion Threads - https://groups.google.com/forum/#!searchin/railo/pd4ml$20OR$20cfdocument%7Csort:date
Unresolved Issues in Railo Jira as of June 2014 - https://issues.jboss.org/browse/RAILO-1493?jql=project%20%3D%20RAILO%20AND%20status%20in%20(Open%2C%20%22Coding%20In%20Progress%22%2C%20Reopened)%20AND%20text%20~%20%22cfdocument%22
PD4ML Tag Library Reference - http://pd4ml.com/taglib/index.html
Header height limit - http://pd4ml.com/support/html-css-to-pdf-rendering-issues-f3/pd4ml-page-header-header-height-t134.html

Bruce Kirkpatrick

unread,

Jun 25, 2014, 8:21:27 PM6/25/14

to ra...@googlegroups.com

The Web kit pdf thing is a very nice alternative which I've used with success. I also have a railo thread hang issue with cfdocument which only happens after the server has been running a while. I think I won't use cfdocument anymore based on what you guys are discussing here. Maybe it would be interesting to make a custom tag that emulates cfdocument behavior but uses webkit. This would make it a faster switch. In case anyone doesn't know, the webkit one is very easy and relies on a fast c binary

Nando Breiter

unread,

Jun 26, 2014, 4:12:27 AM6/26/14

to ra...@googlegroups.com

Bruce,

I assume you've incorporated "the web kit pdf thing" into a CFML web application. Is that correct? If so, can you give a few pointers how it is accomplished?

Thanks!

Nando

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

On Thu, Jun 26, 2014 at 2:21 AM, Bruce Kirkpatrick <br...@farbeyondcode.com> wrote:

The Web kit pdf thing is a very nice alternative which I've used with success. I also have a railo thread hang issue with cfdocument which only happens after the server has been running a while. I think I won't use cfdocument anymore based on what you guys are discussing here. Maybe it would be interesting to make a custom tag that emulates cfdocument behavior but uses webkit. This would make it a faster switch. In case anyone doesn't know, the webkit one is very easy and relies on a fast c binary

--
Did you find this reply useful? Help the Railo community and add it to the Railo Server wiki at https://github.com/getrailo/railo/wiki
---
You received this message because you are subscribed to the Google Groups "Railo" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/railo/aa2b79a9-92b4-4093-9487-3f8e29b56822%40googlegroups.com.

Bruce Kirkpatrick

unread,

Jun 26, 2014, 10:02:47 AM6/26/14

to ra...@googlegroups.com

I did it with CFML last night. I was using it with php previously on a client project.

If you have cfdocument somewhere, you just need to wrap the html with cfsavecontent instead.

then write that variable to disk as a file.

You have to install the binary files (bin directory only) from the download on http://wkhtmltopdf.org/ to /usr/local/bin/ on linux. Make sure the files have chmod 775.

Now, I'm not sure if cfexecute would have permission to execute this on your system, but you could try or adjust your permissions to allow it.

But once you've done the above, you can generate the pdf like this:

then you can use <cfcontent file="/path/to/pdfOutput.pdf" deleteFile="yes" type="application/pdf">

to serve the file directly in that request or do other things.

If you have any trouble it's going to be related to permissions to execute wkhtmltopdf.

The default options for wkhtmltopdf work great assuming your html is using inches/cm and not pixels. There are plenty of options too if you look at the docs.

On my app, I further made this into a simple function and I don't use cfexecute, but instead pass messages securely to an asynchronous php cron job that monitors a directory for new messages. This is how I was able to disable cfexecute/java completely, and only run specific commands that my message passing system allows. I further made the execution of it validate the paths used and disabled the ability to generate a pdf from http/https urls since I didn't want it to be possible to download local urls bypassing the firewall. I do this because I want to prevent CFML from having too much system access. All this is part of my larger open source project now. I also correct filesystem permissions in the cron job before returning the message to cfml.

Make sure the user isn't able to modify the paths to avoid security problems or thoroughly validate them if they can. For example, if they did something like htmlFile=/path/to/../../../../etc/passwd or htmlFile=http://127.0.0.1:8888/railo-context/admin/server.cfm?evil=stuff, they might be able to make a pdf of important system files or get pass the firewall. You can replace ../ and ./ with / and convert \ to / and then validate the path is in the expected directory before executing it.

Bruce Kirkpatrick

unread,

Jun 26, 2014, 11:34:06 AM6/26/14

to ra...@googlegroups.com

I realized you can't really trust the user to upload the html at all I guess unless you validate all the links in the html and javascript too. Probably best to disable javascript and local files too. Then you could parse the html's links more easily and force the domain to match or throw an error. Like whitelist only certain hostnames. Most apps probably don't allow the html to be edited by user in a dangerous way though.

I think adding these flags is probably a good / easy first step that will probably be functional enough though:

--disable-javascript --disable-local-file-access

They won't be able to link to system files at least.

Reply all

Reply to author

Forward