bruno wrote: > java.jago wrote: > > >>>If you want to choose the owner password, >>>and you want this password to be used for >>>creating a PDF on the client side, you can >>>only protect this password 'psychologically'. >>>Meaning you can obfuscate it, but a hacker >>>will always be able to retrieve it. >>> >>> >> >>Thanks, >> >>Actually the program would do everything - the user is not prompted for >>a password. The pdf should also be save from him! >> > > Then why create the PDF at the client side? > Why not create it on the server side?
The client has all the pictures - it is an option to send all the pictures and an XML file and let the server do it. I am currently considering what the best way to do it is...both options as its pro and cons - every hour I change my mind and think the other one is better ;) > > >>That's also a reason >>why I can't use an unencrypted pdf and SSL - this would the user just to >>read it from his disk, if he figures out where it is stored. >> >> > > Why do you store the PDF on disk? > Why don't you send it as a stream? > Actually the amount of data per pdf (because of many big pictures) is huge. Also I want to be able to continue broken uploads. So far I can do it with FTP. This continue function I use like a black box - probably internally it is done with streams - so yes, I probably could use streams and continue, but then I would have to get out the code and examine it. The point is, the code is very stable by just using it as it is - as a ftp upload/continue toolkit. I don't know if it will be similarily stable when I extract code and use it directly without the high level ftp interface. Or do you know of a stream the directly supports SSL and Resume of broken data transfers ? (actually I am a SSL dummy - I will have to read more about it soon). So far I think I will use SSL as you suggested. Still I will encrypt the pdf (or is the encryption part very time consuming). I know that this encryption can be broken - but well, we would still have SSL. > >>I believe Zelix Klassmaster encrypts Strings in Java - so >>"password_Example" becomes "F43Jff§234554" >> >>However - this is just done to distract people who decompile the code >>and who want to understand what the code is doing by looking at the Strings. >> >> > > That's what I meant with 'psychological' protection. > br, > Bruno Cheers, jago _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions
