starred/App-Store-Connect-CLI

Fork 0

mirror of https://github.com/rudrankriyam/App-Store-Connect-CLI.git synced 2026-04-25 23:55:51 +03:00

[GH-ISSUE #567] Auth: add experimental Apple ID web-session mode for UI-only endpoints #159

New issue

Closed

opened 2026-02-26 21:33:50 +03:00 by kerem · 2 comments

kerem commented

2026-02-26 21:33:50 +03:00

Owner

Originally created by @rudrankriyam on GitHub (Feb 16, 2026).
Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/567

Summary

Introduce an explicitly opt-in authentication mode that allows asc to call App Store Connect web-only endpoints that are not accessible via API key/JWT.

This is not intended to replace API-key auth. It is a narrowly scoped escape hatch for specific workflows that are otherwise blocked.

Why this matters

Some operational workflows are high value but not available via the public App Store Connect API.
To make those workflows AI/CI-drivable, the project needs a safe, explicit mechanism to provide web-session auth material.

Examples of workflows that may depend on this:

Resolution Center messaging with App Review
creation of new app records (if not supported by the public API)

Current state (verified)

asc is API-key/JWT based.
There is no support for Apple ID web session cookies, CSRF headers, or provider/team selection state.
The offline OpenAPI snapshot does not include several web-only capabilities.

Security constraints

Web-session material is extremely sensitive (effectively “act as the account”).
Any implementation must:

never print session material
redact it in debug logs
avoid storing it by default
make opt-in explicit and hard to enable accidentally

Proposed UX

Opt-in flag

Add a global flag (name bikeshed):

--experimental-web-session

Session input

Accept session material via environment variables only:

ASC_WEB_SESSION (opaque string)

Optional supporting env vars (if required by the server behavior):

ASC_WEB_SESSION_CSRF (opaque)
ASC_WEB_SESSION_PROVIDER (team/provider selection)

Scope limitation

Web-session mode should only be used for commands that explicitly declare support for it.
All other commands should continue using API key auth exclusively.

Behavior requirements

If --experimental-web-session is not set, commands must not attempt web-session calls.
If --experimental-web-session is set but required env vars are missing, return a usage-style error (exit code 2).
Add aggressive redaction in --api-debug output.
Provide clear warnings in help text about security + 2FA.

Implementation notes

Implement as a separate HTTP client path (cookie jar + required headers).
Avoid any attempt to automate login/2FA.
- The model should be “user supplies a session”, not “CLI logs in”.

Test plan

cmdtests: usage validation + redaction behavior (ensure session values never appear in stderr/stdout)
unit tests for:
- header injection
- cookie jar wiring
- opt-in gating

Acceptance criteria

Web-session mode is opt-in and clearly marked experimental.
Session material is never printed.
Commands that don’t support web-session mode are unaffected.
make test passes.

Originally created by @rudrankriyam on GitHub (Feb 16, 2026). Original GitHub issue: https://github.com/rudrankriyam/App-Store-Connect-CLI/issues/567 ## Summary Introduce an **explicitly opt-in** authentication mode that allows `asc` to call App Store Connect **web-only** endpoints that are not accessible via API key/JWT. This is not intended to replace API-key auth. It is a narrowly scoped escape hatch for specific workflows that are otherwise blocked. ## Why this matters Some operational workflows are high value but not available via the public App Store Connect API. To make those workflows AI/CI-drivable, the project needs a safe, explicit mechanism to provide web-session auth material. Examples of workflows that may depend on this: - Resolution Center messaging with App Review - creation of new app records (if not supported by the public API) ## Current state (verified) - `asc` is API-key/JWT based. - There is no support for Apple ID web session cookies, CSRF headers, or provider/team selection state. - The offline OpenAPI snapshot does not include several web-only capabilities. ## Security constraints Web-session material is extremely sensitive (effectively “act as the account”). Any implementation must: - never print session material - redact it in debug logs - avoid storing it by default - make opt-in explicit and hard to enable accidentally ## Proposed UX ### Opt-in flag Add a global flag (name bikeshed): - `--experimental-web-session` ### Session input Accept session material via environment variables only: - `ASC_WEB_SESSION` (opaque string) Optional supporting env vars (if required by the server behavior): - `ASC_WEB_SESSION_CSRF` (opaque) - `ASC_WEB_SESSION_PROVIDER` (team/provider selection) ### Scope limitation Web-session mode should only be used for commands that explicitly declare support for it. All other commands should continue using API key auth exclusively. ## Behavior requirements - If `--experimental-web-session` is not set, commands must not attempt web-session calls. - If `--experimental-web-session` is set but required env vars are missing, return a usage-style error (exit code 2). - Add aggressive redaction in `--api-debug` output. - Provide clear warnings in help text about security + 2FA. ## Implementation notes - Implement as a separate HTTP client path (cookie jar + required headers). - Avoid any attempt to automate login/2FA. - The model should be “user supplies a session”, not “CLI logs in”. ## Test plan - [ ] cmdtests: usage validation + redaction behavior (ensure session values never appear in stderr/stdout) - [ ] unit tests for: - header injection - cookie jar wiring - opt-in gating ## Acceptance criteria - [ ] Web-session mode is opt-in and clearly marked experimental. - [ ] Session material is never printed. - [ ] Commands that don’t support web-session mode are unaffected. - [ ] `make test` passes.

kerem closed this issue

2026-02-26 21:33:50 +03:00

kerem commented

2026-02-26 21:33:50 +03:00

Author

Owner

@rudrankriyam commented on GitHub (Feb 26, 2026):

Closing as resolved by #758, which introduced the detached experimental Apple web-session auth flow () and web-session-backed unofficial commands.

@rudrankriyam commented on GitHub (Feb 26, 2026): Closing as resolved by #758, which introduced the detached experimental Apple web-session auth flow () and web-session-backed unofficial commands.

kerem commented

2026-02-26 21:33:50 +03:00

Author

Owner

@rudrankriyam commented on GitHub (Feb 26, 2026):

Clarification: resolved by #758, including the detached experimental Apple web-session auth flow via asc web auth and related web-session-backed unofficial commands.

@rudrankriyam commented on GitHub (Feb 26, 2026): Clarification: resolved by #758, including the detached experimental Apple web-session auth flow via asc web auth and related web-session-backed unofficial commands.