RyoKusnadi opened a new pull request, #9335:
URL: https://github.com/apache/devlake/pull/9335
### Summary
**Problem:** A Jira Cloud connection that uses a long token (for example a
scoped service-account token) passes Test Connection, but fails after it is
saved. Opening the connection or its data scopes returns HTTP 500 with `illegal
base64 data at input byte 252`.
**How it happens:** The token is stored encrypted and base64 encoded, which
makes it longer than the plain token. The `token` column of
`_tool_jira_connections` is `varchar(255)`, so the saved value is cut off (or
the write is rejected on strict MySQL modes). Reading it back, the `encdec`
serializer cannot decode the cut value. Test Connection works because it uses
the token from the request, not the database.
**Cause:** `helper.AccessToken.Token` has no explicit column type
(`backend/helpers/pluginhelper/api/connection_auths.go`), so the column was
created as `varchar(255)`.
**Fix:** Add a Jira migration `20261104_change_connection_token_to_text.go`
that changes `_tool_jira_connections.token` to `text`, using `ModifyColumnType`
as other plugins do (for example GitHub `20260819_expand_text_columns.go`).
Changing the shared `AccessToken` tag would not touch existing tables, so a
per-plugin migration is needed anyway.
**Scope:** Other plugins that embed `helper.AccessToken` (gitee, incidentio,
testmo, pagerduty, circleci, grafana_irm, linear, clickup, youtrack, bamboo,
github, tempo, rootly, opsgenie, slack, sonarqube) could have the same limit. I
left them out to keep this PR to the reported Jira case; I can follow up if the
maintainers want it. `password` (basic auth) is also `varchar(255)` but those
values are short. Connections that already saved a cut token must have the
token entered again.
**Testing:** Added `TestChangeConnectionTokenToText`. It checks that `Up`
calls `ModifyColumnType("_tool_jira_connections", "token", "text")` and that
the script is registered in `All()`. Before registering, it failed with
`migration version 20261104120000 is not registered`. After, it passes. Ran `go
vet ./plugins/jira/models/...`, `go test ./plugins/jira/models/...`, `gofmt
-l`. The migration itself was not run against a real MySQL or Postgres
database, and the full suite and e2e tests were not run.
**Risk:** Low. Only the Jira token column type changes (`MODIFY COLUMN ...
text`). Existing values are kept. Rolling back means changing the column back
to `varchar(255)`, which would cut long tokens again.
### Does this close any open issues?
Closes #9328
### Other Information
None.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
