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

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2782
-----------------------------------------------------------------------
 Ticket             | 2782
 Updated By         | Jan Schneider <jan at horde.org>
 Summary            | S/MIME Sign using browser capabilities
 Queue              | IMP
 Version            | HEAD
 Type               | Enhancement
 State              | Feedback
 Priority           | 1. Low
 Owners             | Horde Developers, Michael Slusarz
-----------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2006-07-27 02:06) wrote:

> 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.