2 Correct answers
I did not get an answer from Adobe but I found that PDFReactor required a JVM setting if it was not running with a graphicl inferface. So in the jetty start.ini I added -Djava.awt.headless=true restarted Jetty and it worked. Ubuntu has a GUI so it kind of threw me as to why this would work. But in did. This was on a developer addition of ColdFusion2025. I then had a docker container with coldfusion2023 that had the same issue. I checked it heare and it worked as well.
So for now this appears to b
...
Charlie, thank you for your help and here are my final notes:
To summarize, we had wanted to setup on Red Hat Enterprise Servers a single instance of the PDF Manager to handle calls from multiple ColdFusion servers ( currently running coldfusion 2023).
If you follow the Adobe instructions you will get the fonts that go in usr/share/fonts, but what you will not see is that first the PDFReactor underlying the remote pdf service requires a JVM flag -Djava.awt.headless=true, that goes in to jett
...
49
Replies
Charlie,
A t work I don''t have admin rights on the PDFMaanger Server so I have requeted the change.
By @iclark3509
There you go. That is an example of the security risks I have been pointing out right from the start.
You've been going on about needing access/rights for the Add-On PDF-Generation Service. Why? It doesn't make sense to me. Which is why I requested that you explain your use-case to the forum.
Let's call the ColdFusion instance on which the Add-On Service is registered the first-party. This first-party delegates the responsibility for generating PDFs to a second-party, namely, the Add-On Service. Both are server-side. Why would you, as third-party or client, want to have the rights, hence the responsibility, for generating PDFs? And not just any rights, but Administrator rights.
Isn't it sufficient that you, the client, can make an HTTP request for a PDF to the first-party server, FP_CF? That normally requires no Administrator rights. The ColdFusion server FP_CF then delegates PDF-generation to the Add-On Service, after which FP_CF sends the result to you, the client. I have demonstrated this in an earlier post, providing a sample of the client code and server code.
Access to server back-end services is restricted for a reason. If you are allowed access, and are given permission to remotely run the services concerned, what will prevent malicious access through the same, or similar, backdoor? Beware that the favour you are asking of the System Administrator is the kind of social-engineering request that malicious hackers make.
Well, those questions aside, I'm just focused on the technical matter of a given cf instance talking to a given remote pdf service--and the issues that can arise (and some that Ian has confirmed).
By @Charlie Arehart
To be clear, I, too, am focused on the technical matter of a given cf instance talking to a given remote pdf service. My questions, about use-case and configuration, are vital in this matter. Reread my last post, bearing the following in mind, and you will see that.
Though I miss clarity on the two questions, I have so far been using some working assumptions. My first assumption is the following use-case.
ColdFusion 2023 has been installed on a Linux version (CF1) that doesn’t support running PDFg. So, @iclark3509 and team have had to install and run the PDFg Add-On Service separately on Windows (or some other compatible Operating System), and registering it, of course, with the ColdFusion running on that Operating System (CF2).
To summarize,
- CF2: Windows or some other compatible Operating System with ColdFusion installed, as well as the ColdFusion Add-On (PDFg) Service. The Add-On Service is registered with ColdFusion, possibly as a remote service via IP and port.
- CF1: Linux ColdFusion 2023 server with no PDF generation capability, but which makes HTTP requests to CF2 to get PDFs generated using CF2’s PDFg engine.
Some implications of this for @iclark3509 :
- Request/Response:
The HTTP request from CF1 to CF2 could be something like this:
On CF1: requestPDF.cfm<cfhttp url="http://[CF2_IP_ADDRESS]:[CF2_PORT]/generatePDF.cfm" method="post" result="pdfResult" timeout="10"> <cfhttpparam type="formField" name="htmlContent" value="Some content from an HTML form-field (from CF1)"> </cfhttp> <!--- Handle response ---> <cfif pdfResult.statusCode EQ "200 OK"> <!-- Serve directly to browser --> <cfheader name="Content-Disposition" value="inline; filename=remote_generated.pdf"> <cfcontent type="application/pdf" variable="#pdfResult.fileContent.toByteArray()#"> <cfelse> <cfoutput>Failed to generate PDF. Error: #pdfResult.statusCode#</cfoutput> </cfif>
The response code on CF2 could be something like this:
On CF2: generatePDF.cfm<cfparam name="form.htmlContent" default="Default form-field content (from CF2)"> <!--- Use cfhtmltopdf to leverage the PDFg Add-On ---> <cfhtmltopdf name="pdfDoc"> <cfoutput>#form.htmlContent#</cfoutput> </cfhtmltopdf> <!--- Stream the PDF back to CF1 ---> <cfheader name="Content-Disposition" value="inline; filename=remote.pdf"> <cfcontent type="application/pdf" variable="#variables.pdfDoc#"> - Settings
Working assumptions: On CF2 the Add-On Service is installed separately. Coldfusion 2023 is actually installed on 127.0.0.1:8500. Assumed: the server's IP is 192.168.178.108. This is set with domain name devhost in the hosts file. During installation the Add-On service is registered with IP 192.168.178.108. It is further assumed that the default port for remote access is 5500.
For reference, see Priyank's post in this previous thread on a similar issue: https://community.adobe.com/t5/coldfusion-discussions/cfdocument-hang-timeout-error/td-p/1921811
There are 2 ways to verify:
1st way to verify:
Navigate to [ADD-ON_SERVICE_INSTALLATION_DIRECTORY]/etc/. Open the file jetty.xml in an editor. Ensure that it contains an element that looks like this:
<call name="addConnector">
<arg>
<new class="org.eclipse.jetty.server.ServerConnector">
<arg><ref id="Server"/></arg>
<set name="host"><property name="jetty.host" default="192.168.178.108"/></set>
<set name="port"><property name="jetty.port" default="5500"/></set>
</new>
</arg>
</call>(If you face problems binding with 192.168.178.108, then experiment by replacing it with 0.0.0.0, which will accept all remote connections. I hope you begin to see potential vulnerabilities and security risks. Beware. Even with internal IP addresses, RBAC security measures may be bypassed here.)
2nd way to verify:
Open the ColdFusion Administrator on CF2. Navigate to Data & Services > PDF Service. You should see two services registered: one with 127.0.0.1:8997 and one with 192.168.178.108:5500. Confirm that the setting 192.168.178.108:5500 matches the values in the jetty.xml file. Click on the button "Verify All Service Managers". Then click on the button to start the service manager.
Finally, remember that the above is all based on assumption. The aim is to give you suggestions on further debugging, experimentation and exploration.
At work I do have a ticket open. The admins are working with Adobe but like me they are not having any luck.
By @iclark3509
Nice! I hope Adobe folks will see this and get cracking.
AdChoices