Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Add a command that prints a Connect access token for other tools

オープン
  • 何か問題がありますか？
#21 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
43/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
authentication, cli

調査の方向性

Start by reading the existing posit connect login and server selection commands to find how saved credentials are loaded, refreshed, and persisted. Then check how commands handle non-interactive errors and machine-readable output. Done means a token command supports the proposed server selection and output modes, refreshes and saves credentials when needed, and exits without prompting when credentials are unavailable or refresh fails.

索引モデルが issue の本文から書いたものです。

説明

enhancement

Summary

Add a command that prints a valid Connect access token for a saved server, refreshing it first if needed. Other tools could then use the credentials from posit connect login without reading posit-cli's credential store themselves.

posit connect token [-s URL | -n NAME] [--format json]

Motivation

posit connect login makes OAuth the recommended way to sign in to Connect, so users don't have to create and manage API keys. The Connect SDKs (posit-sdk-py and connectapi) still require an API key, so a user who signed in with posit connect login has to create one separately to use them.

The SDKs could read the stored credentials directly, but that would be fragile:

  • The storage format is internal. Tokens live in the system keyring (service rsconnect-python, username {url}:access_token / {url}:refresh_token), with oauth_* fields in servers.json as a fallback. Neither is a public contract, and both would change if the CLI is rewritten (see #19).
  • Refresh tokens rotate. After a refresh, the CLI writes back the new refresh token. If another tool refreshed on its own without writing back with the same keyring and file behavior, the CLI's stored token would stop working, or the other way round. Two writers would also race.
  • R can't easily read a keyring entry written by Python. connectapi would need its own copy of the lookup logic.

A command avoids all three. The CLI stays the only thing that reads, refreshes, and writes stored credentials, and any language can call it. This is the same pattern as gh auth token, gcloud auth print-access-token, git credential helpers, and kubectl exec plugins.

Proposed behavior

  • Server selection works like other commands: -s/--server URL or -n/--name NAME, falling back to CONNECT_SERVER.

  • If the stored access token is expired or close to expiring, refresh it and persist the new tokens before printing.

  • Default output is the bare access token on stdout, so $(posit connect token) works in shell scripts.

  • --format json prints machine-readable output, for example:

    {"access_token": "...", "token_type": "Bearer", "expires_at": 1793000000, "server": "https://connect.example.com"}

    expires_at lets callers call the command again before the token expires instead of waiting for a 401.

  • Print nothing on stdout and exit non-zero when there are no stored OAuth credentials for the server, or when the refresh fails (for example, the grant was revoked). The error message on stderr should say to run posit connect login. Distinct exit codes for "not logged in" and "refresh failed" would let callers give better messages.

  • Never prompt or start an interactive login. Callers are often non-interactive (scripts, notebooks, SDKs).

  • Servers registered with an API key: either print nothing and exit non-zero, or provide a separate opt-in. Printing API keys by default seems riskier than printing short-lived access tokens.

How the SDKs would use it

When the user doesn't pass an API key and CONNECT_API_KEY isn't set, the SDK runs posit connect token -s $CONNECT_SERVER --format json and sends Authorization: Bearer <access_token>. It runs the command again shortly before expires_at, and once more after a 401. An API key always takes precedence, which matches how posit-cli itself handles precedence. This keeps CI and content running on Connect working unchanged.

Open questions

  • Command name: token, auth token, or print-token?
  • Should the JSON output schema and exit codes be documented as a stable interface, so the SDKs can rely on them across posit-cli versions (including a possible rewrite)?
  • Concurrency: if several processes call the command at the same time while a refresh is due, should the CLI lock the store so only one refresh happens?
主要言語
Python
スター
3
フォーク
0
平均マージ
6分
マージ済み PR（30日）
5

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

posit-dev/posit-cli のほかの issue

posit-dev/posit-cli の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。