网页控件开发全过程

    这几天，终于把加密模块的插件做完了。整个学习过程中学到了很多东西，写下这篇BLOG作纪念。本文主要以发现问题--解决问题的模式描述开发过程

    问题的提出：实现可选择算法的基于WEB的加密，以便完成WEB SERVICE的其他服务

    解决方案：初期，经过讨论，准备借鉴OPEN SSL中现有的库开发加密模块，做成客户端，以实现CS模式的加解密功能。

    新的问题： 在实现的过程中就发现了新的问题，如何将加密后的文件上传给服务器，服务器又如何解密。

    解决方案： 利用公私钥机制（PKI）,对流程进行加解密。具体说来，就是用公钥对用户口令及算法加密，并将生成的密文写到文件的头里，服务器端用私钥解密出用户口令，算法等信息，进行相应的web服务，最后再用用户对应的口令和算法回传给用户，供用户解密。

    新的问题：整个流程都需要客户端支持，不能达到任意地点，任意用户的数据加密及WEB服务的需求。且与web上其他服务的联系不够紧密，不易后期的功能完善。

    解决方案：将整个流程改为BS模式，实现完全基于WEB的互动操作。

    新的问题：对于我来说，基于WEB的操作是一个新的领域，一切都要重新开始学习。网络上函数都在哪里实现，怎么实现时最需要解决的问题。

    解决方案：开始着手了解ActiveX插件，认识到想要把插件发布到任意平台的互联网上，必须要以COM（Component Object Model ）的形式发布，即要以DLL或者EXE的形式发布。

    解决方案：打算用MFCl里自带的dll app将写好的函数封装成DLL。

    新的问题：最大的问题就了解COM为了能跨平台，必须要以宽字符的方式写，接口不能有指针，不能调用MFC的函数，不方便调试等一系列困难。也就是说之前写的DLL，是不能够使用的，要么学习C#,在VS平台下写DLL，要么用ActiveX重新写函数。

    解决方案：一方面了解接触C#开始，一方面硬着头皮写代码，做测试。学习相关的知识，一个版本一个版本的测试。经过长时间的摸索之后，终于了解了一般的COM组件的特点。并也发布了一个能使用的客户端COM和服务器端com。

    新的问题：基本功能是实现了，但是对用用户来说，我们总不能告诉每个用户下载插件，并手动注册regsvr32注册插件吧。于是，如何将组件有效的发布到网上，能够使用户在不透明的环境中执行加解密等操作又成了问题。

    解决方案：了解CAB文件和相关发布的语法。将组件都封装成WINDOWS自动安装的CAB文件。

    新的问题：CAB制作的方法，和及其最关键的INF文件怎么写

    解决方案：开始收集网上的资料和别人写的INF文件，自己尝试写配置文件inf。

    新的问题：INF文件按照要求写好了，可是在提示安装后，就是安装和注册不了。

    解决方案：这个问题很棘手，语法，配置打包我做的都很正确。可结果就是不出。调试了2天都没啥进展。突然在CSDN上看见哪位大神的文章（跪拜那位大神@_@），在文章中简短的一句话，却解决了我的大问题！那就是，在add.code的时候，如果DLL（OCX）间有依赖关系，一定要将最根本的DLL放在后面，因为INF执行的顺序是从后向前。例如：

    clientCOM.dll依赖libeay32.dll，那么在ADD.CODE中要写成：
[Add.Code]
ClientCOM.dll=ClientCOM.dll
libeay32.dll=libeay32.dll

    否则在安装的时候就会报错！

    新的问题：组件确实安装好了，可是由于没有数字签名，会默认的被浏览器给拦截。

    解决方案：自己下载了数字签名的制作工具和签名工具，尝试做了个简单的数字签名，但是效果仍不理想。系统还是会认为是非安全插件。只能从IE的安全选项里修改。

    新的问题：修改IE安全选项的工程，比我想像的复杂，因为对于用户来说，既不能将IE的安全性修改的太低，这样有悖于我们安全加密的初衷，又要完成下载和支持插件的基本功能。所以要找到最为核心的选项。有的机器还会出现不支持脚本运行的错误提示。

    解决方案：穷举法+网上资料查阅+测试。终于找到原因并成功安装。

    

    至此，这个项目基本功能完成。