关于weblogic:运维攻坚之bpm-token无效问题

10次阅读

共计 4595 个字符，预计需要花费 12 分钟才能阅读完成。

某我的项目在 weblogic 降级失败后进行回滚，回滚后环境接口无法访问，报 500 异样，接口为 BPM Service 客户端程序，谬误如下：

SEVERE: <.> getTokenType: invalid token: e0FFU31EbGdrK0IxSlV1WkFMM0doc2dlMUJxdWpjQmEza0tzZGNncnlOSUlLdnFaT0QrY1pyanBBa0d0MTdURHhqbmx4SWJ1d3hvMGsxNmZyaUJFcDIvbGd3MkFWUjRCUXVZdFhvemcxZmprQm83akFoS3pMSWVxeG1DT213VkJpUW5rUWhzQ3lVSmRUT204dXdUUmI2bnlsdEg4bTducTFBWVd0eDVKWjdVSHRiRndsRkRxcjQrZnBVKzBoV0lkc1lRZXQ2VlZkSDRtNUp0V05LYW1SdGNMNWZOUE0rVTVtaEhYYWU5czg4c1VLNHIvenFDN05GTXFieGl6YXJubkd6ZHhTSEZRcUxiRTlmK3ZaNzlLMVlCNExmbkJhL0pSY2hvanlHZ0ZyQWJLdVhJbz0=
SEVERE: <.> Invalid Token Error in Verification Service.
Invalid Token Error in Verification Service. Received invalid token in getTokenType.
Verify that correct token is passed.

ORABPEL-30503

Invalid Token Error in Verification Service.
Invalid Token Error in Verification Service. Received invalid token in getTokenType.
Verify that correct token is passed.

    at oracle.bpel.services.workflow.verification.impl.Token.getTokenType(Token.java:545)
    at oracle.bpel.services.workflow.verification.impl.Token.isSameValue(Token.java:314)
    at oracle.bpel.services.workflow.verification.impl.VerificationService.isInternalWorkflowContext(VerificationService.java:689)

从谬误日志上看是 token 问题，首先就要搞清楚 token 是怎么来的，通过排查，整顿出 token 的逻辑如下

1. 用户在登录页输出用户名明码登录
2. 后盾登录 bpm 获取 token
3.bpm token 通过加密后作为 jwt 的 claim 放入 jwt token 中
4. 用户带上 jwt token 获取代办
5. 后盾解码 jwt token，从 jwt 中获取 bpm token 的 claim
6. 解密 bpm token
7. 带上 bpm token 调用 bpm api

还有一个比拟重要的信息是，登录获取 token 的接口和调用 bpm api 的接口不在同一个 war 包里，所以一开始狐疑是两边 bpm 相干 jar 包版本不一样，比方登录生成 token 用的 jar 包和调用 bpm api 用的 jar 包如果版本不一样，那么 token 就可能无奈被辨认，而后都是朝着这个方向去排查，试了很多计划

两边都将依赖通过 library-ref 形式援用 soa.workflow 库
两个接口放入同一个 war 包
两边都通过间接引入 bpm-service.jar 包形式调用 bpm api

以上形式都失败后，回过头来看谬误日志

Invalid Token Error in Verification Service.
Invalid Token Error in Verification Service. Received invalid token in getTokenType.
Verify that correct token is passed.

    at oracle.bpel.services.workflow.verification.impl.Token.getTokenType(Token.java:545)
    at oracle.bpel.services.workflow.verification.impl.Token.isSameValue(Token.java:314)
    at oracle.bpel.services.workflow.verification.impl.VerificationService.isInternalWorkflowContext(VerificationService.java:689)

因为该项目标后盾咱们没有权限，因而也用不了 arthas 进行调试，但还是通过其余环境找到了 oracle.bpel.services.workflow.verification.impl.Token.getTokenType(Token.java:545) 所在的 jar 包地位${SOA_HOME}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar，代码如下

public static Type getTokenType(String token) throws WorkflowException {if (token == null)
        throw new WorkflowException(new IllegalArgumentException());
    List<String> tokenList = CommonUtil.split(token, ";;");
    Type type = Type.GENERIC;
    if (tokenList != null && tokenList.size() < 3) {Object[] errorObjs = {"getTokenType"};
        DiagnosticService.log(18, DiagnosticService.DIAGNOSTICS_ERRORS, "getTokenType: invalid token:" + token);
        throw new WorkflowException(30503, errorObjs);
    }
    String typeStr = tokenList.get(1);
    if (Type.GENERIC.toString().equals(typeStr))
        return Type.GENERIC;
    if (Type.INTERNAL.toString().equals(typeStr))
        return Type.INTERNAL;
    if (Type.TASKFLOW_INTERNAL.toString().equals(typeStr))
        return Type.TASKFLOW_INTERNAL;
    return Type.GENERIC;
}

比拟外围的代码是以下两行

List<String> tokenList = CommonUtil.split(token, ";;");
if (tokenList != null && tokenList.size() < 3) {Object[] errorObjs = {"getTokenType"};
        DiagnosticService.log(18, DiagnosticService.DIAGNOSTICS_ERRORS, "getTokenType: invalid token:" + token);
        throw new WorkflowException(30503, errorObjs);
}

对 token 应用分隔符 ;; 进行切割，如果长度小于 3 那么就会抛出 30503 异样和谬误日志一样，但从日志中咱们能够看到 token 为

e0FFU31EbGdrK0IxSlV1WkFMM0doc2dlMUJxdWpjQmEza0tzZGNncnlOSUlLdnFaT0QrY1pyanBBa0d0MTdURHhqbmx4SWJ1d3hvMGsxNmZyaUJFcDIvbGd3MkFWUjRCUXVZdFhvemcxZmprQm83akFoS3pMSWVxeG1DT213VkJpUW5rUWhzQ3lVSmRUT204dXdUUmI2bnlsdEg4bTducTFBWVd0eDVKWjdVSHRiRndsRkRxcjQrZnBVKzBoV0lkc1lRZXQ2VlZkSDRtNUp0V05LYW1SdGNMNWZOUE0rVTVtaEhYYWU5czg4c1VLNHIvenFDN05GTXFieGl6YXJubkd6ZHhTSEZRcUxiRTlmK3ZaNzlLMVlCNExmbkJhL0pSY2hvanlHZ0ZyQWJLdVhJbz0=

并没有分隔符;;，从 token 的流程能够看出，token 是通过加密，生成 token 代码如下:

String wforig = ibpmCntx.getToken();
String wf = Utils.encryptUsingWLES(wforig);
wf = JWTokens.encodeBase64(wf);
claims.put("workflowContext", wf);

encryptUsingWLES 调用 weblogic 本身加密服务进行加密，weblogic 加密能够参考之前的这篇文章
encodeBase64 是把加密过的 token 进行 base64 编码

把 token 依照 base64 解密再用 weblogic 解密后，也的确失去了失常的 token

8b261e0a-85e7-4006-88f9-51f4a6baf887;;G;;kHUwUEZ4hbQaZATQaU1gdDDLInpm0Dv7JaDTnUyGKKSXH4qzqQtqi7k+U60mE127gPQhOxPV8M4fZLDzA6Tjm/CaBXHxboiuiNa9EB/dnxeBkU/qI0m+LUsivLbaFDiKCzhTMmGgMiqZPgxv+s3E9A==

能够看到的确蕴含分隔符 ;; 所以能够确定的是 bpm client 在解析 token 是并没有解密，下载 war 包反编译查看代码，的确没有解密就间接用

String wf = (String)jw.getClaim("workflowContext");
request.setProperty("workflowContext", wf);

服务器上的 ear 和 svn 上的 ear 都没有解密的代码，最初因为几年前帮这个我的项目解决过问题无心中留了一个包，找到了正确的包，部署下来后问题解决

String wf = (String)jw.getClaim("workflowContext");
wf = JWTokens.decodeBase64(wf);
wf = Utils.decryptUsingWLES(wf);

request.setProperty("workflowContext", wf);

如果有服务器权限实这个问题用 arthas 一下子就能找到问题起因，没有服务器权限的运维就是坑。

正文完