Decompose token endpoints in scan output

This commit is contained in:
mpabi
2026-04-26 20:05:18 +02:00
parent 5f0da59aa2
commit 840f8badf9
4 changed files with 94 additions and 43 deletions
+11 -10
View File
@@ -305,22 +305,23 @@ Typowy wynik:
```text
items
item source id credential user has_token sync endpoint
---- ----------- ---------- ---------- ---------- --------- ----- --------------------------------
1 repo r1 auth u1 yes yes http://77.90.8.171:3001
1 tokens.json t1 store u1 yes yes http://77.90.8.171:3001
item source id server scheme host port credential repo_user store_user token sync
---- ----------- ---------- ------ ------ --------------- ----- ---------- --------- ---------- ----- ----
1 repo r1 gitea http 77.90.8.171 3001 auth u1 u1 yes yes
1 tokens.json t1 gitea http 77.90.8.171 3001 store u1 u1 yes yes
```
Jesli remote istnieje, ale ma URL bez `LOGIN:TOKEN@`, wynik bedzie mial
w wierszu `repo` wartosci `credential=plain` i `has_token=no`. Jezeli ten sam
w wierszu `repo` wartosci `credential=plain` i `token=no`. Jezeli ten sam
endpoint istnieje w `tokens.json`, drugi wiersz tego samego `item` pokaze
`source=tokens.json`, `id=t1` i `has_token=yes`.
`source=tokens.json`, `id=t1`, `store_user=u1` i `token=yes`.
Ten sam numer `item` oznacza jedna pare logiczna dla jednego endpointu. Wiersz
`source=repo` pokazuje stan remote, a wiersz `source=tokens.json` pokazuje stan
lokalnego store. Kolumna `sync` jest flaga zgodnosci calej pary repo/store.
Kolumna `id` pokazuje identyfikator miejsca przechowywania tokena: dla repo jest
to nazwa remota, na przyklad `r1`, a dla store nazwa tokenu, na przyklad `t1`.
Endpoint jest rozbity na `server`, `scheme`, `host` i `port`.
Przyklad:
@@ -384,10 +385,10 @@ repo_root<TAB>...
token_path<TAB>...
items
item source id credential user has_token sync endpoint
---- ----------- ---------- ---------- ---------- --------- ----- --------------------------------
1 repo r1 plain no no http://77.90.8.171:3001
1 tokens.json t1 store u1 yes no http://77.90.8.171:3001
item source id server scheme host port credential repo_user store_user token sync
---- ----------- ---------- ------ ------ --------------- ----- ---------- --------- ---------- ----- ----
1 repo r1 gitea http 77.90.8.171 3001 plain u1 no no
1 tokens.json t1 gitea http 77.90.8.171 3001 store u1 u1 yes no
status
item<TAB>value
+7 -3
View File
@@ -105,11 +105,15 @@ Kolumny w tabeli `items`:
- `item` - numer porownywanego endpointu
- `source` - `repo` albo `tokens.json`
- `id` - identyfikator miejsca tokena: remote `r1` dla repo albo token `t1` dla `tokens.json`
- `server` - typ serwera, na przyklad `gitea`
- `scheme` - schemat URL, na przyklad `http`
- `host` - host endpointu, na przyklad `77.90.8.171`
- `port` - port endpointu, na przyklad `3001`
- `credential` - typ wpisu: `auth`, `plain`, `store` albo `missing`
- `user` - login odczytany z URL albo ze store
- `has_token` - `yes` albo `no`, czyli czy dane zrodlo ma token dla endpointu
- `repo_user` - login odczytany z remote URL-i repo
- `store_user` - login odczytany z `tokens.json`
- `token` - `yes` albo `no`, czyli czy dane zrodlo ma token dla endpointu
- `sync` - `yes` albo `no`, czyli czy para repo/store jest zgodna
- `endpoint` - endpoint serwera bez sekretu, trzymany jako ostatnia kolumna i przycinany do szerokosci tabeli
Tabela nie wypisuje sekretu tokena. Jezeli token jest w remote, `id` pokazuje
nazwe remota, na przyklad `r1`. Jezeli token jest w `tokens.json`, `id`