Tickets :: Comment on [#2782] S/MIME Sign using browser capabilities

* Your Email Address
* Spam protection	Enter the letters below: . . __.. .\ / __ \ /(__ \ / >< / ` \/ .__) \/ / \\__.
Comment	>> Completely agree with you, thanks for the comment. > >> When I was coding this, I thought about exposing the MIME creation > >> function _createMimeMessage($to, $body) in a way I can call it AJAX > >> style, so the double submit would not be needed. I would just replace > >> my javascript code that composes the MIME hackishly and make an AJAX > >> call the server side to compose it, then continue signing and finally > >> submit it. However, I preferred to leave this strategy for later > >> discussion with you. Besides, I don't think we could call the MIME > >> composing part alone, could we? What do you think about it? > > > > Yeah, I thought about using AJAX too initially, but I guess the form > solution is easier for a start. > > > >> Getting back to your idea, I also thought about it, though I am not > >> sure how to double submit the form. > >> The user first click the submit, we set actionID to COMPOSE_MIME to > >> compose the MIME and not send it. The page would render again but > >> here we need a javascript function to hook in body onload event and > >> re-submit the form, this time setting actionID to > >> SEND_MESSAGE_AS_IS so no other action is taken, only send the > >> messages. > > > > Correct. > > > >> This is much like splitting current actionID 'send_message' in two. > >> One that composes, the other just sends messages away. > > > > Correct. > > > >> I think we need to find a way o reusing the code block of actionID > >> 'send_message' but not sure how. I tried to change as little as I > >> could. > > > > That's not too hard, the first case block would be called for > "compose_mime" and "send_message", the second for "send_mime" and > "send_message". You only need to take care that the first block > doesn't break out at the end if the action is "send_message". > > > >> We also would need to add another config preference other than > >> IMP_SMIME_ENCRYPT so not to override current signing functionality. > > > > Is it possible to detect through the crypto api if client side > crypting/signing is available? > > > >> Then I checked out HEAD to produce this patch we are discussing, but > >> I can not run this checked out source as it is, since I do not know > >> how to configure it with apache. All modules are at the same level > >> wich is different from release code where IMP directory goes inside > >> Horde directory and so forth. In short, can you help me get up and > >> running in Apache this checked out version of IMP so I can test the > >> changes? > > > > Read docs/INSTALL and ask on the mailing list.
Attachment
Watch this ticket

Saved Queries