On Wed, Dec 19, 2012 at 10:39 PM, Ihe Onwuka <ihe...@gm...> wrote:
> The application I am developing has an option to upload and digitally
> sign a file. However when my post to the server includes the digitally
> signed markup in the instance I get an xforms-submit-error (I can
> successfully submit when I don't upload the digitally signed content).
>
> I have affirmed that the instance is well-formed by cutting and
> pasting the display from the XSLTForms debugger and running XMLLint on
> it.
>
> The next thing I have tried is to access information about the
> submission error via the event() function however I just get undefined
> for every option I try so I'm guessing context information on events
> is not implemented.
>
> Fundamentally I want to diagnose the submission error but apart from
> being told it happened on the trace log there doesn't seem to be any
> more information available.
OK problem solved.
Claudius's cryptographic module allows digital signage at the element
level with the default being to embed the digital signature in the
element being signed.
The intractability of the error was on account that post signage, the
XForm would not submit XML that was perfectly well formed and gave no
clue that anything else was amiss.
As ever the inspiration for the solution came from an enforced period
away from the computer.
I changed the options on the signage to reverse the embedding
process, that is instead of the default, embedding the digital
signature in the element, I now embed the element in it's digital
signature and lo and behold I was able to submit the XForm.
The reason I suspected this would make a difference was that I am
digitally signing an element which is base64Binary and has an xsi:type
set accordingly. The default cryptographic embed changes this element
to one of mixed content which I suspect invalidates the typing. This
must be something that is validated during submission, if it is and
such validation is in accordance with the spec then can I suggest
some sort of diagnostic message to this effect - i.e that the XML is
not valid.
May I also suggest a reconsideration of the default Cryptographic
signage option from 'enveloped' to 'enveloping' (or detached) since
'enveloped't has the capability of invalidating your XML as has been
seen from my example.
|
