fix: externalize JWT signing secret

[28Hus]

Summary

The JWT signing secret was hardcoded in both the shared user module and gateway service. Anyone who could read the public repository could forge valid HS512 tokens and impersonate arbitrary users.

The application stores tokens in Redis after successful login and uses this state for checkLogin and logout. However, the gateway's protected routes do not query Redis. They only verify the JWT signature and expiration time, so a forged token does not need any corresponding server-side cache entry.

This change removes the hardcoded secret and requires it to be provided by the deployment environment.

Changes

• Remove the hardcoded JWT secret from both JWT utility implementations.
• Load the secret from the INDEX12306_JWT_SECRET environment variable.
• Inject the configured secret into the user service and gateway service.
• Fail application startup when the secret is missing.
• Add the required configuration to aggregation and microservice profiles.
• Document JWT secret generation and rotation in README.md.

Security Impact

Before this change, the public repository secret could be used to create arbitrary HS512 JWTs containing attacker-controlled:

• userId
• username
• realName

The gateway accepted these claims for protected routes without checking whether the token had been issued by the login flow or existed in Redis.

Verification

The following checks passed locally:

• Maven build for the gateway, aggregation service, user service, ticket service, and order service.
• Gateway starts successfully when INDEX12306_JWT_SECRET is configured.
• Gateway fails during startup when the secret is missing.
• No copy of the previous hardcoded secret remains in the source tree.

Deployment Notes

Existing deployments must configure INDEX12306_JWT_SECRET before upgrading:

export INDEX12306_JWT_SECRET="$(openssl rand -base64 64 | tr -d '\n')"

The same secret must be configured for the user service and gateway within the same deployment. Different environments should use different secrets.

After rotating a leaked secret, all relevant services should be restarted so that tokens signed with the old secret are no longer accepted.

Scope

This PR addresses the publicly exposed hardcoded JWT signing key.

The existing Redis token storage is not currently used by the gateway authorization filter to validate protected requests. Adding server-side token-state validation would be a separate behavior change and is not included in this PR.