http://www.csdn.net/Develop/read_article.asp?id=24859
欢迎大家在此提出自己的见解。

解决方案 »

  1.   

    还有这样的办法解决,在服务器端定义一个方法
      procedure checkLogin(const UserName, Password: WideString); safecall;
      定义一个全局变量LoggedIn为 boolean
      获取数据时检查LoggedIn是否为真
    在checkLogin内容为以下procedure TXXX.Login(const UserName, Password: WideString);
    begin
      {
      检测UserName,Password 是否为安全用户
      ...     }
      {如果成功}
      LoggedIn := True;
      {否则}
      LoggedIn := false;
      raise Exception.Create('Not logged in');
    end;客用端以DCOM为例 如下在 dcom onlogin 事件中加入
    DCOMConnection1.AppServer.Login(UserName, Password);
    这样就可以防止只要知道DCOM GUID就可以连接到服务器上的安全问题
      

  2.   

    谈谈我的作法吧(不好请不要扔砖头,要扔也要扔金币).Client通过 AppServer.Login 实现登录验证过程,在此过程中,确认了合法用户后,再
    把 TDataSet 和 TProvider 连接起来
    把 TDataSet 和 TConnection 连接起来
    设置 TDataSet.SQL
      

  3.   

    上面的方法我都赞同,
    login方法也比较好,
    实际上来说,最简单的是设一个标志变量,
    第一次读取数据时,如果是发送的密码是正确的,就改标志为true,
    以后在每次Before操作时,比较一下就可以了,
    当然,所有的DataSet都可以用同一个方法,呵
      

  4.   

    Mark,如果用HTTPS可以吗? 到哪里搞证书?
      

  5.   

    eboywy(飞影) :COM+能通过关闭的135,4444,6666端口吗???
      

  6.   

    Erice(白雪公猪)那是数据库和操作系统的问题啊。
    黑客可以绕过你的应用程序直接对数据库或操作系统的缺陷进行攻击。
    这和MIDAS没有关系。
      

  7.   

    我也说一下我的方法吧
    我的中间层实际上是一个dataset和TdatasetProvider都没有
    我在中间层定义了一个dataset和tdatasetprovider的动态数组
    然后定义一个createprovider方法和destroyprovider方法
    在需要时,由客户端调用createprovider动态生成一个,不要时调用destroyprovider释放掉
    这样客户端在设计时间是不可能得到中间层的datasetprovider的
    并且中间层也不需要保持那么多的datasetprovider占用过多的内存
      

  8.   

    不要只是把RemoteDataModule简单的看作数据处理模块就行了,
    即然RemoteDataModule是一个COM组件,
    那么就能用上COM/COM+的安全解决方案,
      

  9.   

    还有这样的办法解决,在服务器端定义一个方法
      procedure checkLogin(const UserName, Password: WideString); safecall;
      定义一个全局变量LoggedIn为 boolean
      获取数据时检查LoggedIn是否为真
    在checkLogin内容为以下procedure TXXX.Login(const UserName, Password: WideString);
    begin
      {
      检测UserName,Password 是否为安全用户
      ...     }
      {如果成功}
      LoggedIn := True;
      {否则}
      LoggedIn := false;
      raise Exception.Create('Not logged in');
    end;客用端以DCOM为例 如下在 dcom onlogin 事件中加入
    DCOMConnection1.AppServer.Login(UserName, Password);
    这样就可以防止只要知道DCOM GUID就可以连接到服务器上的安全问题谈谈我的作法吧(不好请不要扔砖头,要扔也要扔金币).Client通过 AppServer.Login 实现登录验证过程,在此过程中,确认了合法用户后,再
    把 TDataSet 和 TProvider 连接起来
    把 TDataSet 和 TConnection 连接起来
    设置 TDataSet.SQL
    //-----------------------------综合以上两位仁兄的方法,
    实际中,我们也在项目中采用前提:
     远程数据模块(必需是多实例,部分线程模式,这个很重要)
     远程数据模块中,所有dataset 跟connection 是断开的,也就是说默认不连接数据库。
     
    然后构建成一个login方法
    procedure TXXX.Login(const UserName, Password: WideString);
    begin
      if 
      {
      检测UserName,Password 是否为安全用户
      ...     } then
      begin
      {如果成功}
      设置,所有DATAset 指向正确的 connection.
      end;
      
      {否则..什么事情也不做}
       end;
      

  10.   

    通过对一些实际的应用情况的总结比较,我比较赞同stubborndonkey和billy_zh的做法!
      

  11.   


    1.可以参照\Demos\Midas\Intrcpt的例子加密数据,使用InterceptGUID
    2.RDM不输出DataSetProvide,全通过调用RDM的函数实现,对于函数可以只调用一个公用函数,重写TClientdataset
    有兴趣的可以参看
    http://search.csdn.net/expert/topic/53/5310/2003/10/18/2368941.xml中的讨论
      

  12.   

    我比较赞同huhaojie(似水流年) 的方法。客户端通过DataRequest方法把加密串及用户名及密码发送到中间层如果加密串正确则中间层的TADOConnection组件连接到数据层,这时你就可以验证用户及密码是否有误如果不正确则重新跟数据层断开连接。连接串设置为空。无论客户端是否知道数据提供者也没有办法去跟数据层连接呀。你还可以在数据层上只提供一个提供者(用来验证使用),只有在正确登录后你才创建基它的数据提供者。这样也不需改很多代码又方便。
      

  13.   

    huojiehai(海天子)那一贴答案非常精彩!
      

  14.   

    如果ScktSrvr能通过得到客户断传来的用户,如果不是合法用户则不连接,这样什么问题都
    解决。关键是scktsrvr,大家还是想办法改它比较好一点.
      

  15.   

    改掉IPROVIDER的实现方法,让其返回空不就行了嘛????
      

  16.   

    对于scktsrvr,有源码可以修改,可以在上面做安全文章,可以做得像代理服务一样实现IP过滤,做到只有用户设置的IP可以访问,很简单
      

  17.   

    楼主看这个我以前发的,现在再回头看很爽:
    http://search.csdn.net/Expert/topic/2368/2368941.xml?temp=.1435968
      

  18.   

    可以参照\Demos\Midas\Intrcpt的例子加密数据,使用InterceptGUID使用 des3, rsa, zlib 对数据做处理,
    应该就安全多了,集成ScktSrvr 到应用程序,只允许访问内部COM对象,防止访问系统其它对象将访问限制到接口,不允许出现万能接口,或者越权访问的接口
      

  19.   

    当然了,登录验证也是必要的,每次请求,需要提供cookie 数据