If you have a form that contains a digital signature and has a policy applied to it, if you ever want to edit that signature (or form for that matter) you'll have problems, since the policy is protecting the form. What you'll need to do is use the "unlockPDF" service to temporarily unlock the form. You can only use this in a short lived process, so place that service and whatever you need to do to the form in a subprocess, and use that subprocess in your main process. At the end of the subprocess, the policy will be reapplied to the for automatically.
Another very important ote is that the security for the subprocess must be set to be invoked as a user that has access to the policy (so set the "invoke as" parameter as a specific user)*.
Note* I was have alot of problem with this, as I was getting the "No veiw permissions" error in my logs. The reason was due to the domain of my users. For some reason LC didn't like it, so once i recreated the users and policy into another domain, all became right with the world.
Monday, July 27, 2009
VirtualBox - Creating a template harddrive
Rather than install windows and have to customize each harddrive to the way that you want it, you can simply create one and then clone that harddrive using this command;
VBoxManage clonehd source.vdi destination.dviSimple as that.
Labels:
linux
Wednesday, July 15, 2009
Digital Signatures and Rights management
I've just figured out that if you want to apply any type of policy onto a form (like thru a custom renderer) you need to apply the policy as the first thing. The reason being is that if you apply the policy afterwards, it breaks the digital signature.
Oddly enough this also applies if you reader extend the form. If you apply the reader extension THEN apply the policy, you'll get an error saying that you can't apply a policy on a signed form. Strange, eh?
Oddly enough this also applies if you reader extend the form. If you apply the reader extension THEN apply the policy, you'll get an error saying that you can't apply a policy on a signed form. Strange, eh?
Labels:
Digital Signatures,
LiveCycle,
Process,
Reader Extensions
Monday, July 13, 2009
Digital Signatures and Process Flows
Learning something new, when using digital signatures in a document, the data type of the form should be Document Form. This is exactly like an xfaForm, except you hve the ability to render the form just once and then once submitted the form as a whole document gets transferred over.
Read http://livecycleapps.wordpress.com/2009/02/11/livecycle-process-variable-cheat-sheet/ for more info
The only thing is trying to access field values of a document form type. I'll update when i have that figured out.
update* Looks like i'll have to use the export data service, then use xpath on that xml to access the different values. So you'd have to use something like this in the xpath;
Its also helpful to get values from the form if you don't happen to have a schema attached.
Read http://livecycleapps.wordpress.com/2009/02/11/livecycle-process-variable-cheat-sheet/ for more info
The only thing is trying to access field values of a document form type. I'll update when i have that figured out.
update* Looks like i'll have to use the export data service, then use xpath on that xml to access the different values. So you'd have to use something like this in the xpath;
/process_data/formVar//nameOfField
Its also helpful to get values from the form if you don't happen to have a schema attached.
Labels:
Digital Signatures,
LiveCycle,
Process
Subscribe to:
Posts (Atom)