在 Worklight 中开发基于适配器的安全验证

安全验证是移动应用开发中一个很重要的组成部分,Worklight 有着完善的安全验证框架,提供了多种形式的安全验证方式。本文将以 Worklight 5.0.3 版本为基础,首先介绍 Worklight 中安全验证的基本概念,然后,通过围绕一个示例,来介绍如何开发基于适配器的安全验证。

岳 泓, 高级软件工程师, IBM  

岳泓,就职于 IBM 中国开发中心,有多年 J2EE、BPM、SAP 项目开发和实施经验,目前关注 SAP 和手机开发相关项目。



仲 光庆, 高级软件工程师, IBM

仲光庆,就职于 IBM 中国开发中心,有多年 J2EE 和 SAP 相关的项目开发和实施经验,目前关注 SAP 和云相关项目。



石 广, 软件工程师, IBM

石广,就职于 IBM 中国开发中心,有多年 J2EE 项目开发和实施经验,目前关注 SAP 和手机开发相关项目。



2012 年 12 月 06 日

免费下载:IBM® Worklight Mobile Platform
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

Worklight 安全验证简介

安全验证是应用开发中的一个重要的组成部分,对移动应用开发亦是如此,Worklight 作为一个业界领先的移动应用开发和管理平台,提供了完善的安全验证框架。

Worklight 安全验证框架中的基本概念

安全验证用于防止对某些特定资源的未经许可的访问,在 Worklight 中,我们使用其验证框架来保护 Worklight 中的 实体(entity),如 应用适配器 以及 静态资源

Worklight 提供了声明式的方式来配置保护规则,来实现对实体的未经授权的访问保护,声明规则由下面两个概念组成:

  • security test: 由一个或多个 ream 组成,用于保护 Worklight 的实体。
  • realm: realm 定义了处理用户验证的业务逻辑,它又由以下几个概念组成。
    • challenge handler:客户端组件,用于侦测服务器端是不是在发送一个需要安全验证的请求,如果是, 则收集用户身份信息,并发送至服务器端。
    • authenticator:服务器端组件,用于收集客户端发来的用户身份信息。
    • login module:服务器端组件,用于接收 authenticator 收集到的用户身份信息,验证该身份并创建用户身份对像。

Worklight 服务器端可以定义一个或多个 authenticator,authenticator 又分为下面三种类型:

  • 基于表单的 authenticator:用于基于表单的安全验证请求。默认实现为 com.worklight.core.auth.ext.FormBasedAuthenticator。
  • 基于适配器的 authenticator:用于使用适配器过程(procedure,类似于 Java 方法或函数的概念)来 搜集和验证 用户身份。默认实现为 com.worklight.integration.auth.AdapterAuthenticator。
  • 基于 HTTP 头的 authenticator: 同上述 authenticator 不一样,该 authenticator 并不需要由客户端提交用户身份信息,而是直接从 HTTP 头中检查相关的属性值。

我们在多数情况下,仅需直接使用 Worklight 提供的 authenticator,如有复杂的情况,我们也可以使用 Java 来实现自己所需的 authenticator。在本例中,我们将使用基于适配器的 authenticator 的默认实现,下面接着介绍基于适配器的安全验证。

基于适配器的安全验证简介

在 Worklight 中,适配器用于 获取信息和执行动作,它可以连接多种类型的后台系统,如数据库﹑ Cast Iron 等,Worklight 可以通过调用适配器过程来连接第三方系统,并可执行相应的操作,图一为适配器请求流程示意图:

图 1. 适配器请求流程示意图
图1 适配器请求流程示意图

开发适配器主要就是开发适配器中的过程(procedure),过程是适配器中的核心组成部分,它提供了连接第三方系统并执行所需业务逻辑的能力。在开发时,我们需要在适配器的 XML 声明文件中声明该适配器中的过程,然后在 JavaScript 文件中来实现定义的过程,当然我们也可以使用 Java 来实现过程。在本例中,我们使用了 JavaScript 来实现过程。

在实际项目中,由于身份信息可能来源于第三方系统,如数据库﹑ LDAP 服务器等,此时,我们便希望能够使用适配器来连接第三方系统,正如前面的章节所述,Worklight 提供了基于适配器的安全验证能力。

需要注意的是,当使用基于适配器的安全验证方式时,我们可以在适配器中实现完整的身份验证逻辑,而此时,login module 并不是必须的,任何其他声明的 login module 将作为一个额外的身份验证逻辑在适配器执行后被调用。

同其他方式的安全验证流程类似,Worklight 在拦截到一个访问受保护资源的请求后,会首先检查该请求是否含有合法的用户身份,如果是,则给予访问权限,并返回请求的数据;如果没有合法的用户身份,则启动验证流程,只有在验证流程成功后,才能授予访问权限,返回请求的数据。如图 2 所示。

图 2. 基于适配器的安全验证处理流程图
图 2 基于适配器的安全验证处理流程图

示例介绍

基于适配器的安全验证方式是实际项目中常会使用的一种安全验证方式,本文给出了一个基于适配器的安全验证的示例,并使用该安全策略来保护适配器中的过程,读者也可以根据自己的需要使用安全策略来保护应用和静态资源。

本文的示例分为两个部分:适配器和客户端应用,图 3 给出了示例的请求处理流程,该处理流程同图 2 所示的标准请求处理流程类似:

图 3. 示例请求处理流程
图 3 示例请求处理流程
  1. 请求访问客户端应用中的页面 AdapterAuthentication.html
  2. 页面中的 JavaScript 调用受保护的过程 protectResource
  3. 安全验证框架被触发,调用适配器中的 onAuthRequired
  4. 客户端页面中的 JavaScript 检查 authRequired 属性,判断是否需要验证
  5. 如已验证,显示请求页面,显示相应的 DIV 内容,并隐藏特定的 DIV 内容,如登录输入框。至此,请求处理流程结束。
  6. 如需要验证,则显示请求页面,显示相应的 DIV 内容,如登录输入框,并隐藏特定的 DIV 内容。
  7. 用户输入相应身份信息,并触发身份验证请求,相应的适配器中的过程 doLogin 将被触发,用于验证身份信息。
  8. 如果验证成功,则转至第 5 步。
  9. 如果验证失败,则转至第 6 步,并显示相应的错误消息。

从开发角度看,本例的开发主要分为适配器的开发和客户端应用的开发,由于只是用于演示用途,本例并未设计复杂的业务逻辑。在适配器中,只有几个简单的过程;在客户端应用中,页面中主要分成两块,一块是在验证后才会显示的,另一块则在没有验证的时候显示。下面我们将介绍如何开发本例及相应的 Worklight 安全验证框架中的要点。


示例开发

配置服务器端的安全验证策略

当安全验证策略确定后,我们就可以着手配置安全策略,但在配置之前,我们首先需要创建一个 Worklight 项目,本示例选择创建一个混合应用(Hybrid Application)类型的项目,在向导窗口,输入应用名为 AdapterAuthentication,在下面的小节“开发客户端应用”中,我们将基于这里生成的应用做修改。

图 4. 创建 Worklight 项目
图 4 创建 Worklight 项目

项目创建成功后,我们可以在项目视图中看到已经生成好的文件,打开 server->conf,我们即可找到用于安全配置的文件 authenticationConfig.xml,如图 5 所示。

图 5. 安全配置文件 authenticationConfig.xml
图 5 安全配置文件 authenticationConfig.xml

正如本文在第一小节提到的,服务器端的安全配置需要配置 security test 和 realm,在服务器端,realm 由 login module 和 authenticator 组成,下面我们首先配置 login module,打开文件 authenticationConfig.xml,在节点 loginModules 加入清单 1 所示的代码片段。

清单 1. login module 代码片段
 <loginModule name="StrongDummy"> 
 <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className> 
 </loginModule>

由于示例使用适配器来执行安全验证逻辑,我们并不需要有额外的安全验证逻辑,所以这里使用了 NonValidatingLoginModule,如果这里定义了其他的 login module,该 login module 将在适配器中的逻辑执行后被执行。

配置好了 login module,便可在同一个文件中加入 realm 的配置,找到节点 realms,并加入清单 2 所示的代码片段。

清单 2. realm 代码片段
 <realm loginModule="StrongDummy" name="AdapterAuthRealm"> 
 <className>com.worklight.integration.auth.AdapterAuthenticator</className> 
 <parameter name="login-function" value="AuthAdapter.onAuthRequired"/> 
 <parameter name="logout-function" value="AuthAdapter.onLogout"/> 
 </realm>

com.worklight.integration.auth.AdapterAuthenticator 为 realmAdapterAuthRealm 的 authenticator 的实现,该 authenticator 表示我们将使用适配器过程来进行安全验证,login-function 和 logout-function 是我们 realm 中的两个重要属性,当 Worklight 框架侦测到一个针对受保护资源的访问请求,会调用 login-function 中所定义的方法,当获得一个退出登录请求时,则调用 logout-function 中所定义的方法,可以发现属性值的格式为“适配器名 . 过程名”。清单 2 中已经给出了示例中所用到的适配器的两个过程,它们将在下一个小节中介绍。

现在,我们就可以在同一个配置文件中加入 security test 的配置,如清单 3 所示。

清单 3. security test 配置代码片段
 <securityTests> 
        <customSecurityTest name="AdapterAuth-securityTest"> 
            <test isInternalUserID="true" realm="AdapterAuthRealm"/> 
        </customSecurityTest> 
 </securityTests>

在文件中,我们可以看到已经有些被注释掉的 security test 的配置,而其中的 security test 又可以分为下面三种:

  • webSecurityTest:用于包含 Web 安全相关的 realm。
  • mobileSecurityTest:用于包含移动安全相关的 realm。
  • customSecurityTest:用于包含自定义开发的 realm。

由于示例使用了适配器来保护对受保护资源的访问,我们这里使用 customSecurityTest,realm 则是上面所声明的 AdapterAuthRealm。

到这里,我们就已经配置好了安全验证策略,在下面的适配器开发中,我们将会使用到本节声明的 security test 和 realm。

开发适配器

Worklight 提供了三种类型的适配器:SQL 适配器﹑ HTTP 适配器以及 Cast Iron 适配器,本例使用了 HTTP 适配器,但由于我们的适配器比较简单,实际上并不需要连接第三方支持 HTTP 协议的系统。

在项目浏览器视图中,可以找到 adapter 文件夹,我们即可选中文件夹 adapters,右键选中 NewWorklight Adapter,如图 4 所示。

图 6. 创建适配器
图 6 创建适配器

Fig6_CreateAdapter.jpg

在弹出的窗口中,选中 Adapter type 为 HTTP Adapter,并输入 Adapter name 为 AuthAdapter。

图 7. 输入适配器信息
图 7 输入适配器信息

选择“Finish”,即可看到项目视图中新生成的文件夹 AuthAdapter,该文件夹包含下面三个文件,如图 6 所示:

  • AuthAdapter.xml,适配器的配置和声明文件,用于配置和第三方系统连接的相关属性及声明该适配器中对其他应用或适配器所公开的过程。
  • AuthAdapter-impl.js,用于实现上面 XML 文件中所声明的过程。
  • filtered.xsl,用于定义所处理的数据的 schema,由于本例较为简单,无需对该文件做任何修改。
图 8. 适配器文件列表
图 8 适配器文件列表

如前文所述,本例实际上并未使用适配器连接第三方系统,所以在适配器的配置和声明文件中,我们并无需配置 connectivity 节点,使用生成的默认值即可,目前,Worklight 的 HTTP 适配器支持 REST 和 SOAP 调用。除了 connectivity 之外,我们还在配置和声明文件中,声明了两个公开方法 doLogin 和 protectResource,清单 4 给出了配置和声明文件片段。

清单 4 配置和声明文件片段
 <connectivity> 
 <connectionPolicy xsi:type="http:HTTPConnectionPolicyType"> 
 <protocol>http</protocol> 
 <domain>rss.cnn.com</domain> 
 <port>80</port> 
 </connectionPolicy> 
 <loadConstraints maxConcurrentConnectionsPerNode="2" /> 
 </connectivity> 

 <procedure name="doLogin"/> 

 <procedure name="protectResource" securityTest="AdapterAuth-securityTest"/>

protectResource 为受保护的过程,当有请求调用该过程时,相应的 security test 将会被调用,doLogin 则是一个公开的未受保护的过程,该过程将被客户端页面调用,用于验证用户身份。

配置好了 XML 文件之后,我们便可在 JavaScript 文件中实现所配置的公开方法,同时可以添加其他内部方法,清单 2 给出了 doLogin 方法的实现。

清单 5. doLogin 方法的实现
 function doLogin(username, password){ 

 var userIdentity = { 
 userId: username, 
 displayName: username, 
 loginName: username, 
 attributes: { 
 foo: "bar"
 }, 

 isUserAuthenticated: '1'
 }; 

 //Dummy verify logic, just for demo purpose 
 if (username == password) { 
 WL.Server.setActiveUser("AdapterAuthRealm", userIdentity); 

 return { 
 authRequired: false 
 }; 
 } else { 
 return onAuthRequired(null, "User name or password is wrong."); 
 } 

 }

示例逻辑比较简单,当输入的用户名和密码一样时,我们便认为用户身份信息正确,同时将生成的身份对象设置为当前的活动用户,并返回 authRequired 为 false,注意,第一个参数为上一小节安全配置文件中所声明的 realm。如果用户身份验证失败,则将调用方法 onAuthRequired,该方法亦会在 Worklight 侦测到有访问受保护资源请求时由 Worklight 框架自动调用(见上一小节 realm 的配置),清单 6 给出了 onAuthRequired 和剩下的 2 个方法代码。

清单 6. 适配器中的其他方法
 function onAuthRequired(headers, errorMessage){ 
 errorMessage = errorMessage ? errorMessage : "Auth Required"; 

 return { 
 authRequired: true, 
 errorMessage: errorMessage 
 }; 
 } 

 function protectResource() { 

 //No function code required, this method is just used to 
 //make sure the user is authenticated 
 //Otherwise, login page will be showed. 

 } 


 function onLogout() { 
 //Put any additional log out/clean up logic here 
 //For demo purpose, no code is needed 

 }

通过上面代码片段,可以发现方法 protectResource 和 onLogout 是两个空方法,在清单 4 中我们将方法 protectResource 定义为受保护的方法,所以尽管该方法中没有逻辑,但在调用方法前,依然会进行安全检查;onLogout 方法为 realm 的 logout-function 的属性值,所以该方法会在用户退出登录时被调用,用于清除用户数据等,出于演示用途,本例未添加任何代码。

至此,我们的适配器就开发完毕,下面我们就可以开发客户端应用来验证我们所做的安全配置和适配器。

开发客户端应用

示例的客户端应用主要为一个 HTML 页面,应用为登录前或登录后的用户显示同一个页面,但页面的内容并不一样。由于只是演示用途,我们直接基于创建项目时自动生成的应用上做定制修改,虽然创建项目时自动创建了数个文件,而我们只需要修改其中的一个 JS(AdapterAuthentication.js)文件和 HTML(AdapterAuthentication.html)文件,如图 9 所示。

图 9. 客户端应用文件结构图
图 9 客户端应用文件结构图

在整个客户端应用的开发过程中,我们主要需要做下面的工作:

  1. 修改 HTML 页面,对已验证的用户和未验证的用户添加不同的显示内容。
  2. 修改 JavaScript wlCommonInit 方法,用于调用受保护的过程。
  3. 在 JavaScript 文件中,增加客户端的用户身份信息收集和验证请求提交代码,其核心为 challenge handler。
  4. 在 JavaScript 文件中,增加一个新的方法 checkUser,用于检查用户是否已经过验证。

HTML 页面比较简单,主要目的是能够对已验证的和未验证的用户提供不同的显示内容,并能够给未验证用户提供登录框供用户输入用户名和密码。清单 7 为页面 HTML 代码片段。

清单 7. 页面 HTML 代码片段
 <body onload="WL.Client.init({})" id="content" style='display: none'> 
        <div id="AppDiv"> 
 <div class="header" style="display:none"> 
 <h1>Adapter Authentication Demo</h1> 
 </div> 
            <input type="button" value="Check User" 
            onclick="checkUser()" /> 
            <input type="button" value="Logout" 
            onclick="WL.Client.logout('AdapterAuthRealm',
            {onSuccess:WL.Client.reloadApp})" /> 

        </div> 
        
        <div id="AuthDiv" style="display:none"> 
        <p id="AuthInfo"></p> 
        <hr /> 
       <input type="text" placeholder="Enter username"
        id="AuthUsername"/><br /> 
       <input type="password" placeholder="Enter password" 
       id="AuthPassword"/><br /> 
       <input type="button" value="Submit" id="AuthSubmitButton" /> 
        </div> 

 <script src="js/initOptions.js"></script> 
 <script src="js/AdapterAuthentication.js"></script> 
 <script src="js/messages.js"></script> 
 </body>

在加载页面的过程中,WL.Client.init({}) 会首先被调用,它将调用方法 wlCommonInit。AppDiv 区域用于提供已通过验证的用户所能看到的内容,AuthDiv 区域用户显示为登录用户所能看到的内容,challenge handler 的方法 handleChallenge 会设定这两个 DIV 的 display 属性。

wlCommonInit 方法位于文件 AdapterAuthentication.js 中,我们需要在该方法中调用前面所创建的适配器 AuthAdapter 中的受保护过程 protectResource,这样,在初始化客户端应用页面时,Worklight 的安全机制将会随着受保护过程的调用而被触发,清单 8 列出了方法 wlCommonInit。

清单 8. 方法 wlCommonInit
 function wlCommonInit(){ 
 // Common initialization code goes here 
 var invocationData = { 
 adapter : "AuthAdapter", 
 procedure : "protectResource", 
 parameters : [] 
 }; 
 WL.Client.invokeProcedure(invocationData,{}); 
  
 }

在 AdapterAuthentication.js 文件中,还需要添加核心的客户端安全验证代码,其核心主要是获取和使用 challenge handler

清单 9. 获取和使用 challenge handler
 var authChallengeHandler = WL.Client.createChallengeHandler("AdapterAuthRealm"); 

 authChallengeHandler.isCustomResponse = function(response) { 

 if (!response || !response.responseJSON|| response.responseText === null) { 
 return false; 
 } 
 if (typeof(response.responseJSON.authRequired) !== 'undefined'){ 
 return true; 
 } else { 
 return false; 
 } 

 }; 

 authChallengeHandler.handleChallenge = function(response){ 
 var authRequired = response.responseJSON.authRequired; 

 if (authRequired == true){ 
 $("#AppDiv").hide(); 
 $("#AuthDiv").show(); 
 $("#AuthPassword").empty(); 
 $("#AuthInfo").empty(); 

 if (response.responseJSON.errorMessage) 
    $("#AuthInfo").html(new Date() + " :: " + response.responseJSON.errorMessage); 

 } else if (authRequired == false){ 
 $("#AppDiv").show(); 
 $("#AuthDiv").hide(); 
 authChallengeHandler.submitSuccess(); 
 } 
 };

WL.Client.createChallengeHandler("AdapterAuthRealm") 用于获取 challenge handler,参数为我们所要使用的 realm。Challenge handler 的方法 isCustomResponse 会在每次收到服务器端响应的时候被调用,用于检查是不是需要对该响应做安全验证,当该方法返回为 true 时,意味着 Worklight 框架需要对该响应做安全验证,另一个方法 handleChallenge 随即被调用,用于在需要安全验证的情况下,显示用户身份信息输入选项,并显示相应的错误消息;当返回为 false 时,则意味着用户已通过安全验证,只需调用 submitSuccess 方法来通知 Worklight 框架,表示用户已通过安全验证。

那么 authRequired 的初始值又是如何被设为 true 的呢?当受保护的资源被请求时,Worklight 安全机制随即被触发,realm 配置中所配置的 login-function 将被调用,如清单 6 所示,onAuthRequired 方法会将 authRequired 值设为 true,而在安全验证成功后,该方法则不会继续被调用。清单 10 给出了本例的安全配置片段,详细内容会在下面的小节介绍。

清单 10. 安全配置片段
 <realm loginModule="StrongDummy" name="AdapterAuthRealm"> 
 <className>com.worklight.integration.auth.AdapterAuthenticator</className> 
 <parameter name="login-function" value="AuthAdapter.onAuthRequired"/> 
 <parameter name="logout-function" value="AuthAdapter.onLogout"/> 
 </realm>

本文的主要目的是介绍基于适配器的安全验证,其核心点之一便是如何调用适配器做安全验证,而调用代码也需要添加在 AdapterAuthentication.js 中,清单 11 给出了相应的代码片段。

清单 11. 调用适配器触发验证逻辑
 $("#AuthSubmitButton").bind('click', function () { 
 var username = $("#AuthUsername").val(); 
 var password = $("#AuthPassword").val(); 

 var invocationData = { 
 adapter : "AuthAdapter", 
 procedure : "doLogin", 
 parameters : [ username, password ] 
 }; 

 authChallengeHandler.submitAdapterAuthentication(invocationData, {}); 
 });

上面的代码主要做了三件事:

  1. 为按键的 click 事件绑定 JavaScript 方法,当用户单击页面登录按键时,绑定的 JavaScript 方法将被触发。
  2. 获取页面中的用户名和密码信息
  3. 获取适配器 AuthAdapter 中的 doLogin 对象,并通过执行 submitAdapterAuthentication 来调用适配器中的过程来执行验证逻辑。

至此,我们已经完成了本例的开发工作,下面我们将部署和运行本例。


部署和运行示例

由于我们使用了适配器,所以我们首先需要部署适配置,在项目视图中,右键单击适配器的文件夹,选中“Run As->Deploy Worklight Adapter”,如图 10 所示。

图 10. 部署适配器
图 10 部署适配器

在控制台视图中,如果看到“Adapter deployed successfully”,则表示适配器已经部署成功,如图 11 所示。

图 11. 控制台视图
图 11 控制台视图

同部署适配器类似,我们还需要部署客户端应用,找到应用的文件夹,右键单击,选中“Run As->Build All and Deploy”,如图 12 所示。

图 12. 部署客户端应用
图 12 部署客户端应用

同样,如果控制台视图提示“Application 'AdapterAuthentication' deployed successfully with all environments”,则表明应用已经部署成功,如图 13 所示。

图 13. 部署客户端应用控制台
图 13 部署客户端应用控制台

最后,我们便可以通过控制台(localhost:8080/console)来预览我们的示例,图 14 为初次访问的示例页面。

图 14. 示例初次访问页面
图 14 示例初次访问页面

因为用户还没登录,而我们在页面初始化过程中已经调用了受保护的适配器过程,所以 onAuthRequired 方法被触发,从而在页面上部显示提示消息,提示用户需要登录,当用户输入正确的用户和密码(这里只需要用户名等于密码),即可显示已验证用户所能看到的内容,如图 14 所示。

图 15. 授权用户显示页面
图 14 授权用户显示页面

用户即使再次刷新页面,页面内容也不会变化,因为我们在适配器过程 doLogin 已经将 authRequired 设为 false,这样 Worklight 框架会认为后续请求已经经过安全验证,无需再次进行安全验证,当点击“退出”按键后,则会回到未验证状态,并显示未验证的页面。


总结

Worklight 提供了多种安全验证方式,本文选择介绍了常用的一种方式:基于适配器的验证方式,本文通过一个简单的示例,介绍了基于适配器的安全验证的基本概念,同时介绍了基本的开发步骤以及如何在 Eclipse 中做相关开发,我们在掌握了开发本文示例的基础上,可以根据项目的需要,做进一步的定制开发。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, 移动开发
ArticleID=850333
ArticleTitle=在 Worklight 中开发基于适配器的安全验证
publish-date=12062012