wso2 org list: no endpoint, and no token path for a shell-owned command
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 0
- Forks
- 3
- Avg merge
- 8h 43m
- Merged PRs (30d)
- 60
Description
What is missing
wso2 org list is published in the command reference as "Lists organizations available to the signed-in user" and returns shell.unknown_command. It is one of the nineteen unbuilt commands recorded in #112 §2.
Wave 4 built wso2 org use and wso2 org current, which are local: they write and read Organization on the selected context. org list was deliberately left unbuilt, because it cannot be written today for two independent reasons.
Blocker 1: there is no endpoint
Nothing in this repository knows how to enumerate organizations. There is no control-plane client, no organizations URL, and no response shape to decode. internal/catalog is the only outbound HTTP client in the shell and it reads a public, unauthenticated catalog.
This is adjacent to #112's gap 7 — whether WSO2 Cloud can enumerate a subscribed product set — which is recorded there as needing an answer from outside this repository. The two are not the same question, but they are answered by the same system.
Blocker 2: it needs a token before it can have one
This is the harder one, and it is architectural rather than missing information.
The auth broker narrows every minted token to the selected context's organization and refuses outright when that field is empty (internal/auth/source.go:179). A command whose purpose is to list organizations so a user can choose one runs precisely when no organization has been chosen, so it cannot obtain a token by the route every other authenticated call uses.
It is also shell-owned. auth.Broker is keyed on a module namespace and the capabilities declared in that module's receipt, and a shell command has neither. org list would therefore be the first shell-side consumer of an access token, which is the boundary ADR 0004 exists to define. Building it would settle that architecture question as a side effect of adding a command, which is the wrong order.
What a solution has to decide
- Where a shell-owned command gets a token, and whether ADR 0004 is extended or amended to allow it. Reading the stored session directly would be the first bypass of shell-brokered authentication in the codebase and should not be done casually.
- What identity an organization-less token is minted against, given the broker's current refusal.
- The endpoint, its response shape, its pagination, and the scope the token needs.
Acceptance criteria
-
wso2 org listlists the organizations available to the signed-in identity - It works before any organization has been selected, which is its main use
- No secret, token, or credential value appears in any rendering
-
--output jsonrenders the same facts as an object - The token path a shell-owned command uses is recorded in an ADR, whether as an extension of ADR 0004 or a decision that supersedes part of it
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read internal/auth/source.go around line 179 and docs/adr/0004-shell-brokered-authentication.md first, then review the command reference and the gap in #112. The work needs an external answer on the organizations endpoint and token model before implementation. It is done when the command works without a selected organization, supports table and JSON output without credentials, and records the token path in an ADR.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication, cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100