解决使用gateway后静态资源失效的问题

网友投稿 1216 2022-12-31

解决使用gateway后静态资源失效的问题

解决使用gateway后静态资源失效的问题

关于使用gateway后静态资源失效问题

配置文件方式对应服务配置文件目录提供参考

F12可以看到静态资源路径全部都是加载失败。这是因为我们没有对静态文件进行路由导致。

配置文件方式

贴出主要配置:/static/**表示对静态资源的路由

routes:

- id: home-service

uri: lb://home-service #lb表示从注册中心找到服务

predicates: #路由规则

- Path=/home-service/**, /static/**

- id: user-service

uri: lb://user-service

predicates:

- Path=/user-service/**, /static/**

对应服务配置文件

spring:

resources:

static-locations: 静态资源路径

目录提供参考

记录一次SSO gateway=true 失效的问题

问题发生场景:

当用户在门户登录后(门户集成sso(4.0 版本)单点登录,门户使用自己的登录界面,使用sso中的gateway=true特性实现),经过一段时间后,用户刷新门户,如果门户会话状态和全局sso失效,按照设想是会回到门户登录界面,而不是sso的登录界面,但是有时却回到sso的登录界面,并且浏览器地址栏带有“gateway=true”查询参数

用户在刷新一次浏览器才能回到门户登录界面。

一开始想到是sso中的gateway=true参数失效,在login-webflow.xml文件中增加一个action-state用来再次检查gateway参数,并在decision-state id 为“gatewayRequestCheck”中使用新增加的action-state 对gateway再一次检查。

配置以及代码如下:

xml配置:

login-webflow.xml

test="requestParameters.gateway != '' and requestParameters.gateway != null and flowScope.service != null"

then="gatewayServicesManagementCheck" else="gatewayParameterCheck" />

cas-servlet.xml

c:servicesManager-ref="servicesManager" />

java代码:

public class GatewayParameterCheck extends AbstractAction {

private final Logger logger = LoggerFactory.getLogger(this.getClass());

@NotNull

private final ServicesManager servicesManager;

/**

* Initialize the component with an instance of the services manager.

* @param servicesManager the service registry instance.

*/

public GatewayParameterCheck(final ServicesManager servicesManager) {

this.servicesManager = servicesManager;

}

@Override

protected Event doExecute(final RequestContext context) throws Exception {

final Service service = WebUtils.getService(context);

final HttpServletRequest request = WebUtils.getHttpServletRequest(context);

String gateWayV = request.getParameter("gateway");

if (StringUtils.hasText(gateWayV) && service != null) {

if ("true".equals(gateWayV)) {

logger.info("gateway参数校验,校验信息:gateway={}, 请求服务信息:{}", gateWayV, service.toString());

return yes();

}

}

return no();

}

}

更新到生产环境后,经用户测试发现此方案无效。此方案无效后,只能再次去回归login-webflow的登录流程,总结的流程图如下:

上图只是涉及到登录部分简单截图,不涉及到TGT以及ST。

由上图可以发现,在“ticketGrantingTicketCheck”节点之后,如果TGT不存在,则会去检查gateway参数,如果gateway存在,则会去到节点“gatewayServicesManagementCheck”,如果不存在,则回到节点“serviceAuthorizationCheck”,到该节点一般也就会到sso的登录界面了。

之前在节点“gatewayRequestCheck”后增加了gateway参数再次检查的节点“gatewayParameterCheck”发现无效果。

因此可以排除走这条线的可能性,剩下的只有TGT存在无效到sso登录界面这条线了。在这个action-state之中只是对tgt相关的cookie进行清除,并没有对gateway参数进行检查,因此有可能是问题的所在。

验证猜想。

1. 将TGT的存活时间暂时设置为60秒(默认为2小时),方便测试。

修改配置文件:ticketExpirationPolicies.xml

p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}"

p:timeToKillInSeconds="${tgt.timeToKillInSeconds:60}"/>

2. 重新发布sso程序,从门户认证成功后,等待60秒过后,再次刷新门户系统,发现果然到sso登录界面。重复实现多次发现都时一样。由此可以得出,由于门户使用的TGT失效,并没有检查gateway参数因此跳转到sso的登录界面。

3. 解决方案:只需在action-state 节点中增加对gateway参数的检查逻辑,根据检查的结果到不同的节点即可。新的流程图如下:

在上图中增加节点 “terminateSession”的 条件为“gateway”的transition,当请求中存在gateway参数时,让流程到gatewayRequestCheck节点。

代码:

final HttpServletResponse response = WebUtils.getHttpServletResponse(context);

this.ticketGrantingTicketCookieGenerator.removeCookie(response);

this.warnCookieGenerator.removeCookie(response);

/**

* 检查gateway参数,如果为true,走gatewayRequestCheck

*/

final String hasGateWayParameter = WebUtils.getHttpServletRequest(context).getParameter("gateway");

if (!VTools.StringIsNullOrSpace(hasGateWayParameter) && "true".equals(hasGateWayParameter)) {

return new Event(this, "gateway");

}

return this.eventFactorySupport.success(this);

本地重新编译测试后发现可正常跳转回门户登录界面。将TGT的存活时间恢复默认值,发布到线上后,留意一段时间,发现没有出现改问题,至此解决问题。

总结:

sso login-webflow 登录流程较为复杂,出现问题时,应该根据登录流程图分析判断问题出现在哪些节点上,然后修改相关参数重现问题,之后修改相关逻辑验证以及解决问题。

test="requestParameters.gateway != '' and requestParameters.gateway != null and flowScope.service != null"

then="gatewayServicesManagementCheck" else="gatewayParameterCheck" />

cas-servlet.xml

c:servicesManager-ref="servicesManager" />

java代码:

public class GatewayParameterCheck extends AbstractAction {

private final Logger logger = LoggerFactory.getLogger(this.getClass());

@NotNull

private final ServicesManager servicesManager;

/**

* Initialize the component with an instance of the services manager.

* @param servicesManager the service registry instance.

*/

public GatewayParameterCheck(final ServicesManager servicesManager) {

this.servicesManager = servicesManager;

}

@Override

protected Event doExecute(final RequestContext context) throws Exception {

final Service service = WebUtils.getService(context);

final HttpServletRequest request = WebUtils.getHttpServletRequest(context);

String gateWayV = request.getParameter("gateway");

if (StringUtils.hasText(gateWayV) && service != null) {

if ("true".equals(gateWayV)) {

logger.info("gateway参数校验,校验信息:gateway={}, 请求服务信息:{}", gateWayV, service.toString());

return yes();

}

}

return no();

}

}

更新到生产环境后,经用户测试发现此方案无效。此方案无效后,只能再次去回归login-webflow的登录流程,总结的流程图如下:

上图只是涉及到登录部分简单截图,不涉及到TGT以及ST。

由上图可以发现,在“ticketGrantingTicketCheck”节点之后,如果TGT不存在,则会去检查gateway参数,如果gateway存在,则会去到节点“gatewayServicesManagementCheck”,如果不存在,则回到节点“serviceAuthorizationCheck”,到该节点一般也就会到sso的登录界面了。

之前在节点“gatewayRequestCheck”后增加了gateway参数再次检查的节点“gatewayParameterCheck”发现无效果。

因此可以排除走这条线的可能性,剩下的只有TGT存在无效到sso登录界面这条线了。在这个action-state之中只是对tgt相关的cookie进行清除,并没有对gateway参数进行检查,因此有可能是问题的所在。

验证猜想。

1. 将TGT的存活时间暂时设置为60秒(默认为2小时),方便测试。

修改配置文件:ticketExpirationPolicies.xml

p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}"

p:timeToKillInSeconds="${tgt.timeToKillInSeconds:60}"/>

2. 重新发布sso程序,从门户认证成功后,等待60秒过后,再次刷新门户系统,发现果然到sso登录界面。重复实现多次发现都时一样。由此可以得出,由于门户使用的TGT失效,并没有检查gateway参数因此跳转到sso的登录界面。

3. 解决方案:只需在action-state 节点中增加对gateway参数的检查逻辑,根据检查的结果到不同的节点即可。新的流程图如下:

在上图中增加节点 “terminateSession”的 条件为“gateway”的transition,当请求中存在gateway参数时,让流程到gatewayRequestCheck节点。

代码:

final HttpServletResponse response = WebUtils.getHttpServletResponse(context);

this.ticketGrantingTicketCookieGenerator.removeCookie(response);

this.warnCookieGenerator.removeCookie(response);

/**

* 检查gateway参数,如果为true,走gatewayRequestCheck

*/

final String hasGateWayParameter = WebUtils.getHttpServletRequest(context).getParameter("gateway");

if (!VTools.StringIsNullOrSpace(hasGateWayParameter) && "true".equals(hasGateWayParameter)) {

return new Event(this, "gateway");

}

return this.eventFactorySupport.success(this);

本地重新编译测试后发现可正常跳转回门户登录界面。将TGT的存活时间恢复默认值,发布到线上后,留意一段时间,发现没有出现改问题,至此解决问题。

总结:

sso login-webflow 登录流程较为复杂,出现问题时,应该根据登录流程图分析判断问题出现在哪些节点上,然后修改相关参数重现问题,之后修改相关逻辑验证以及解决问题。

c:servicesManager-ref="servicesManager" />

java代码:

public class GatewayParameterCheck extends AbstractAction {

private final Logger logger = LoggerFactory.getLogger(this.getClass());

@NotNull

private final ServicesManager servicesManager;

/**

* Initialize the component with an instance of the services manager.

* @param servicesManager the service registry instance.

*/

public GatewayParameterCheck(final ServicesManager servicesManager) {

this.servicesManager = servicesManager;

}

@Override

protected Event doExecute(final RequestContext context) throws Exception {

final Service service = WebUtils.getService(context);

final HttpServletRequest request = WebUtils.getHttpServletRequest(context);

String gateWayV = request.getParameter("gateway");

if (StringUtils.hasText(gateWayV) && service != null) {

if ("true".equals(gateWayV)) {

logger.info("gateway参数校验,校验信息:gateway={}, 请求服务信息:{}", gateWayV, service.toString());

return yes();

}

}

return no();

}

}

更新到生产环境后,经用户测试发现此方案无效。此方案无效后,只能再次去回归login-webflow的登录流程,总结的流程图如下:

上图只是涉及到登录部分简单截图,不涉及到TGT以及ST。

由上图可以发现,在“ticketGrantingTicketCheck”节点之后,如果TGT不存在,则会去检查gateway参数,如果gateway存在,则会去到节点“gatewayServicesManagementCheck”,如果不存在,则回到节点“serviceAuthorizationCheck”,到该节点一般也就会到sso的登录界面了。

之前在节点“gatewayRequestCheck”后增加了gateway参数再次检查的节点“gatewayParameterCheck”发现无效果。

因此可以排除走这条线的可能性,剩下的只有TGT存在无效到sso登录界面这条线了。在这个action-state之中只是对tgt相关的cookie进行清除,并没有对gateway参数进行检查,因此有可能是问题的所在。

验证猜想。

1. 将TGT的存活时间暂时设置为60秒(默认为2小时),方便测试。

修改配置文件:ticketExpirationPolicies.xml

p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}"

p:timeToKillInSeconds="${tgt.timeToKillInSeconds:60}"/>

2. 重新发布sso程序,从门户认证成功后,等待60秒过后,再次刷新门户系统,发现果然到sso登录界面。重复实现多次发现都时一样。由此可以得出,由于门户使用的TGT失效,并没有检查gateway参数因此跳转到sso的登录界面。

3. 解决方案:只需在action-state 节点中增加对gateway参数的检查逻辑,根据检查的结果到不同的节点即可。新的流程图如下:

在上图中增加节点 “terminateSession”的 条件为“gateway”的transition,当请求中存在gateway参数时,让流程到gatewayRequestCheck节点。

代码:

final HttpServletResponse response = WebUtils.getHttpServletResponse(context);

this.ticketGrantingTicketCookieGenerator.removeCookie(response);

this.warnCookieGenerator.removeCookie(response);

/**

* 检查gateway参数,如果为true,走gatewayRequestCheck

*/

final String hasGateWayParameter = WebUtils.getHttpServletRequest(context).getParameter("gateway");

if (!VTools.StringIsNullOrSpace(hasGateWayParameter) && "true".equals(hasGateWayParameter)) {

return new Event(this, "gateway");

}

return this.eventFactorySupport.success(this);

本地重新编译测试后发现可正常跳转回门户登录界面。将TGT的存活时间恢复默认值,发布到线上后,留意一段时间,发现没有出现改问题,至此解决问题。

总结:

sso login-webflow 登录流程较为复杂,出现问题时,应该根据登录流程图分析判断问题出现在哪些节点上,然后修改相关参数重现问题,之后修改相关逻辑验证以及解决问题。

p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}"

p:timeToKillInSeconds="${tgt.timeToKillInSeconds:60}"/>

2. 重新发布sso程序,从门户认证成功后,等待60秒过后,再次刷新门户系统,发现果然到sso登录界面。重复实现多次发现都时一样。由此可以得出,由于门户使用的TGT失效,并没有检查gateway参数因此跳转到sso的登录界面。

3. 解决方案:只需在action-state 节点中增加对gateway参数的检查逻辑,根据检查的结果到不同的节点即可。新的流程图如下:

在上图中增加节点 “terminateSession”的 条件为“gateway”的transition,当请求中存在gateway参数时,让流程到gatewayRequestCheck节点。

代码:

final HttpServletResponse response = WebUtils.getHttpServletResponse(context);

this.ticketGrantingTicketCookieGenerator.removeCookie(response);

this.warnCookieGenerator.removeCookie(response);

/**

* 检查gateway参数,如果为true,走gatewayRequestCheck

*/

final String hasGateWayParameter = WebUtils.getHttpServletRequest(context).getParameter("gateway");

if (!VTools.StringIsNullOrSpace(hasGateWayParameter) && "true".equals(hasGateWayParameter)) {

return new Event(this, "gateway");

}

return this.eventFactorySupport.success(this);

本地重新编译测试后发现可正常跳转回门户登录界面。将TGT的存活时间恢复默认值,发布到线上后,留意一段时间,发现没有出现改问题,至此解决问题。

总结:

sso login-webflow 登录流程较为复杂,出现问题时,应该根据登录流程图分析判断问题出现在哪些节点上,然后修改相关参数重现问题,之后修改相关逻辑验证以及解决问题。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:即时设计小程序组件下载(即时设计小程序组件下载网站)
下一篇:app关联小程序(微信关联小程序)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~