Search before asking
Description
The login session lifetime is currently a compile-time constant:
// dolphinscheduler-common/.../common/constants/Constants.java
public static final int SESSION_TIME_OUT = 7200;
It is consumed in one place:
// dolphinscheduler-api/.../api/service/impl/SessionServiceImpl.java
@Override
public boolean isSessionExpire(Session session) {
return System.currentTimeMillis() - session.getLastLoginTime().getTime() >= Constants.SESSION_TIME_OUT * 1000;
}Two problems with this:
- Operators cannot change it without rebuilding and redeploying. Deployments that need a longer session (internal tools behind a VPN, long-running review sessions) or a shorter one (shared environments) have to patch the source and recompile.
- It is declared in
dolphinscheduler-common but only used by dolphinscheduler-api. Because it is a static final int, it is inlined into SessionServiceImpl at compile time, so editing the constant alone is not even sufficient — dolphinscheduler-api must be recompiled too. That is an easy trap for anyone attempting a quick patch.
A secondary consequence: dolphinscheduler-common is a shared jar across master / worker / alert / tools, so changing a constant there forces all of those services to be replaced for what is really an API-only concern.
Proposed change
Move the value into ApiConfig (the existing @ConfigurationProperties(prefix = "api") class that already owns API-server settings such as base-url, audit-enable and traffic-control):
- Add a
Duration sessionTimeout field defaulting to 2 hours, so the out-of-the-box behaviour is unchanged.
- Read it in
SessionServiceImpl#isSessionExpire.
- Drop the now-unused
Constants.SESSION_TIME_OUT.
- Add a validation that rejects zero / negative values.
- Document
api.session-timeout alongside the other api.* options.
Operators would then set it in api-server/conf/application.yaml:
api:
session-timeout: 12h # accepts e.g. 30m, 2h, 1d; defaults to 2h when unset
Note this does not change the expiry semantics: the timeout is still measured from the moment the user logs in (not sliding on activity). Sliding expiration would be a separate, larger behavioural change and is explicitly out of scope here.
Are you willing to submit PR?
Code of Conduct
中文补充：登录会话时长目前写死在 Constants.SESSION_TIME_OUT = 7200，运维不改代码就无法调整。而且因为它是 static final int，会被编译期内联，只改常量不重编 api 也不生效；它又放在被 master/worker/alert/tools 共享的 common 包里，属于把一个 API 专属的配置放错了层次。建议改为 api.session-timeout 配置项（Duration，默认 2h 保持原行为）。注意本改动不涉及过期语义——仍是从登录时刻算的绝对超时，滑动续期不在本次范围内。
Search before asking
Description
The login session lifetime is currently a compile-time constant:
It is consumed in one place:
Two problems with this:
dolphinscheduler-commonbut only used bydolphinscheduler-api. Because it is astatic final int, it is inlined intoSessionServiceImplat compile time, so editing the constant alone is not even sufficient —dolphinscheduler-apimust be recompiled too. That is an easy trap for anyone attempting a quick patch.A secondary consequence:
dolphinscheduler-commonis a shared jar across master / worker / alert / tools, so changing a constant there forces all of those services to be replaced for what is really an API-only concern.Proposed change
Move the value into
ApiConfig(the existing@ConfigurationProperties(prefix = "api")class that already owns API-server settings such asbase-url,audit-enableandtraffic-control):Duration sessionTimeoutfield defaulting to 2 hours, so the out-of-the-box behaviour is unchanged.SessionServiceImpl#isSessionExpire.Constants.SESSION_TIME_OUT.api.session-timeoutalongside the otherapi.*options.Operators would then set it in
api-server/conf/application.yaml:Note this does not change the expiry semantics: the timeout is still measured from the moment the user logs in (not sliding on activity). Sliding expiration would be a separate, larger behavioural change and is explicitly out of scope here.
Are you willing to submit PR?
Code of Conduct
中文补充：登录会话时长目前写死在
Constants.SESSION_TIME_OUT = 7200，运维不改代码就无法调整。而且因为它是static final int，会被编译期内联，只改常量不重编 api 也不生效；它又放在被 master/worker/alert/tools 共享的common包里，属于把一个 API 专属的配置放错了层次。建议改为api.session-timeout配置项（Duration，默认 2h 保持原行为）。注意本改动不涉及过期语义——仍是从登录时刻算的绝对超时，滑动续期不在本次范围内。