We sometimes get inquiries from IT departments on behalf of users trying to open documents encrypted with the FileOpen software. Sometimes the question concerns the general design of the system, sometimes it is specific to a particular error condition. From time to time as these questions arrive we will post answers to this blog. Here's one such message.
"We have a few FileOpen plug-in users that are unable to open PDFs. When attempting to do so, they get error "There was an error contacting the server or the server's response could not be decoded. Please check your internet connection. If the error persists please contact the publisher and present the text of this message".
I have downloaded the latest version of FileOpen from the website, and attempted to open a PDF from <publisher>, but I still get the same error.
>In order to help troubleshoot this, I am hoping that you can provide:
- A generic test PDF from FileOpen that we can use to determine whether this is an issue with using FileOpen itself, or an issue with the publisher of the PDF.
- A host that we can telnet to, and the necessary ports, to determine whether firewall rules are not set properly on our end.
- Any other suggestions that you might have."
Somewhat parenthetically, I'd like to point out the extremely professional structure of this question: the exact text of the error is presented, the questioner seems to have already determined the cause of the problem (firewall blocking access) so asks for data to verify that assumption. For a tech-support person, interactions like this one are a real pleasure.
In response, we can say:
There is a FileOpen test-server at http://www.rightserver.com/fowp that can be used to validate the behavior of the FileOpen client. This server is part of our Toolkit evaluation package, and implements a very simple PermissionServer script, without SSL, and contains document examples that don't require any authentication. At the top of the page there's an anchor link for MachineID, and the four documents in that section will open for any user at any time provided the user has the FileOpen client and an active internet connection. The page also contains links to files that demonstrate some of the other authentication methods, so can be used to validate other behaviors as well.
However, the fact that a document opens from the above site does not necessarily mean that the same machine will be able to open documents from any given publisher using the FileOpen software. Because of the design of our system (publishers are not required to use our server software, and their own implementations can use any port), the specifics of the ports needed for any given document can't be known ahead of time. Nearly all PermisisonServers running the FileOpen software use either port 80 or 443, but this is not a requirement.
The important things to consider if a document doesn't open are:
- Is the FileOpen client installed (check Help>About 3rd Party Plug-ins>FileOpen WebPublisher)? If not, install from http://plugin.fileopen.com/ or http://plugin.fileopen.com/all.html
- Does the error message contain text that suggests that the Publisher's server could not be reached (the one above, or a message with text like "Unable to get server data [FO error #2114, OS error #0].") If so, attempt to open a file from the test site above. If that also fails, check that the machine is connected to the internet and that the local proxy or firewall permits Adobe Acrobat/Reader to communicate over port 80.
- Does the error contain a message that is specific to this document or user, e.g. something like "Document Access Denied: This machine is not registered for access to this document."? If so the technical underpinnings are working properly - the client was able to contact the server and got a response - but there is a business issue between the user and the publisher, i.e. that publisher does not recognize the user or user's machine as having access to the document.
For more on the inner workings of the FileOpen plug-in for PDF, please see the FAQ.