Re: Internet web app - sending .PDF or .PS output direct to user
printer
Steve G wrote On 08/04/06 12:00,:
I have a real brain-teaser here (it may not even be possible). We have
a web app, it will run across the INTERnet (not intra). The app will
generate reports. Currently what we do is:
1. generate the report (over on the server, obviously) as a .pdf file
2. once done, we forward the user to the URL of the .PDF file
3. Since IE knows what to do with filetype .PDF, he kicks off Adobe
Reader and loads the .PDF in the new window.
For non-technology-related reasons, we can't do it this way (the user
must not be allowed to print the output more than once, and of course
once we dump them into Adobe Reader they can hit the Print button all
day, no way for us to stop them).
So we need to figure out how to take this output (we're generating it
with FOP) and dump it out to the user's printer (in other words, we
don't display the file, thereby allowing them to print multiple times;
we simply print it). I'm thinking with the code and the output file
over on the app server, there really isn't a way for me to direct this
output to the printer of a user who is running our app through IE. Or
am I wrong? If I'm right, can anyone think of another way to achieve
this result? Thanks as always.
(Replying to the original because repeated top-posting
intermixed with bottom-posting has made the follow-ups too
difficult for my tired old brain to comprehend.)
I think you're doomed. The closest you can come may be
to use a special printer with cryptographic capabilities:
You'd ship encrypted bits over the wire and forward them (still
encrypted) to the printer, where they'd be decrypted just as
close to the paper as your engineers can manage. Even then,
a sufficiently determined user could try attaching probes to
the outputs of the crypto device.
If you need to let the users provide their own computers
and their own printers, it is going to be impossible to assert
complete control over the printing environment. It is a trivial
matter to install a "printer" that prints to a file, from which
the ordinary local print services can then make as many hard
and soft copies as the user desires.
You might write your own printer driver, something that
prints only to a real physical printer and cannot be fooled
into printing to a file. It'd use all the self-authentication
techniques in the book to guard against tampering -- but even
if it's sure the bits are going across an actual physical cable,
it's never going to be sure they're being printed and forgotten
rather than being recorded for later multiple playback.
What are these documents you're printing? Money? Most
national governments discourage free-lancing ...
--
Eric.Sosman@sun.com