[Bug] Authorization and authentication failures report the wrong cause

Đang mở
  • Có gì không ổn?
#65 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
authentication, authorization, cli

Hướng nghiên cứu

Start with the fs command error handling and reproduce the listed revoked-token, scoped-token, and path-format cases using the commands in the issue. Trace where authentication and authorization failures become CLI messages and exit codes. Done means the failure causes are consistent and actionable, revoked tokens report authentication failures with exit 3, and user-facing errors no longer expose the internal ':' root path.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

ti version

0.2.7 (6c950c77a601d0d55394c4b2f64483ae93d522db, 2026-09-27), bundled ti-drive9 companion 60b63d6

Command family

fs

Operating system and architecture

macOS 14.6, darwin/arm64

Summary

Three problems in the same area. A caller cannot tell what actually failed, and in one case
the message points at a credential that was never used.

Covers observations 11, 10, and 2 from a review of the TiDB Cloud Filesystem documentation.

Problem 1: a deleted or disabled token reports invalid API key and exit 1

Command
ti fs delete-file-system-token --file-system-id "<fs-id>" --token-id "<token-id>"
TI_FS_TOKEN="<the revoked token>" ti fs read-file --path /reports/a.txt
Reproduction steps
  1. Create a file system and an owner token.
  2. Generate a scoped token, and confirm it can read a file.
  3. Revoke it with delete-file-system-token, wait for caches to converge.
  4. Read the same file with the revoked token.
  5. Repeat with disable-file-system-token in place of the delete.
Expected behavior

An authentication failure, exit code 3, with a message naming the file system token.

Actual behavior

Exit code 1, and a message naming an API key that was never supplied:

ti [ERROR]: fs cat: read :/reports/a.txt: invalid API key
ti [ERROR]: fs ls: list :/reports: invalid API key

disable-file-system-token produces the same message, and
enable-file-system-token restores access, so this is not specific to deletion. An owner
token on the same file system kept working throughout, which confirms the credential path
itself was healthy.

The consequence is that a caller reads "invalid API key" and goes to rotate API keys that had
nothing to do with the failure.

Problem 2: a scoped token denial reports two different messages

Reproduction steps
  1. Generate a scoped token allowing read,list on /reports.
  2. Run each command against a path inside the scope without the required operation, and
    against a path outside the scope.
  3. Repeat with a read,list,write scope.
Expected behavior

One message for one class of failure, carrying a reason.

Actual behavior

All 25 denied combinations exit 1, and the message depends on the command rather than on the
path.

  • list-files, read-file, delete-file, create-directory, move-file, describe-file,
    find-files, and search-file-content report fs access denied.
  • copy-file reports an empty HTTP 403: when uploading to a path outside the scope,
    downloading from a path outside the scope, or copying to a remote path outside the scope.
    Copying from a remote path outside the scope reports fs access denied instead.

The empty HTTP 403: carries no reason and reads like a network fault, so a caller cannot
separate an authorization failure from an outage. I could not find a rule that predicts which
message appears.

Problem 3: error text exposes an internal root path spelled :

Actual behavior
ti [ERROR]: fs ls: list :/: fs access denied
ti [ERROR]: fs cat: read :/reports/a.txt: invalid API key

The : prefix is not a path the caller supplied or can act on. It appears in messages a user
is asked to read, and in the same messages the documentation asks them to include in a bug
report.

Sensitive-data confirmation

No API keys, file system or Vault tokens, database credentials, connection strings, SQL, or
customer data appear above. File systems used for these measurements were deleted afterwards.

Ngôn ngữ chính
Go
Star
3
Fork
4
Merge trung bình
3 ngày 19 giờ
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tidbcloud/ti-cli

Tất cả issue của tidbcloud/ti-cli

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.