Come clonare un repository montato

Il repository è visibile nel wiki, ma occorre lavorarci in locale — clone, pull e push da un client git ordinario, senza una licenza propria di Azure DevOps.

Il plugin porta un proxy git a un proprio indirizzo, separato da doku.php. Il client git parla con il wiki e il wiki, tramite l'account di servizio, con Azure DevOps. L'autenticazione avviene con il protocollo HTTP Basic e un token personale, mai con la password del wiki. L'accesso lo decide lo stesso livello del mount che vale nel browser.

showcase non concede deliberatamente alcun diritto di prelievo: il codice sorgente si legge nel browser e nessuno ne prende una copia. Chi ne ha bisogno chiede library o un livello superiore.

L'indirizzo nasce dallo spazio dei nomi del mount trasformando i due punti in barre:

https://www.wvds.it/wiki/lib/plugins/wkdoadogit/git.php/code/dokuwiki-plugins/wkdoadogit

Quell'indirizzo si rivolge al mount code:dokuwiki-plugins:wkdoadogit. Non serve comporlo a mano, perché lo mostrano due punti:

• Il pannello Come ottenere questo repository sopra l'albero, sulla pagina con il browser. Lo vede chiunque abbia il livello 2 o superiore. Oltre all'indirizzo offre il download ZIP e i collegamenti per aprire il repository in Visual Studio Code e in JetBrains.
• L'elenco dei mount nell'amministrazione, nel menu di riga del mount. Lo vedono solo gli amministratori.

Un mount registrato con il segnaposto {lang} ha un indirizzo per lingua. Il modello in sé non è un indirizzo e verrebbe rifiutato.

1. Aprite /doku.php?do=wkdoadogit_tokens. Vi conducono anche il collegamento in fondo al pannello Come ottenere questo repository, il menu di riga del mount e la voce Gestisci i token di accesso git nella tavolozza dei comandi.
2. Inserite un'etichetta, per esempio portatile o CI, e scegliete Crea.
3. Copiate subito il token mostrato. Compare esattamente una volta, perché ne viene memorizzato solo il valore con hash; in seguito non è più recuperabile, nemmeno da un amministratore.
4. I token che non servono più si rimuovono con Revoca nella stessa tabella.

Ogni token rilasciato inizia con il prefisso wkg_, così che uno scanner di segreti o un filtro dei registri lo riconosca a colpo d'occhio.

Quando wkidentity è installato, il rilascio di un token richiede una sessione provata almeno da un'autenticazione ordinaria; l'installazione può innalzare il requisito a un secondo fattore. I token già rilasciati restano validi quando la regola viene inasprita, perciò dopo una modifica rilasciateli di nuovo.

git clone https://www.wvds.it/wiki/lib/plugins/wkdoadogit/git.php/code/dokuwiki-plugins/wkdoadogit

Alla richiesta di autenticazione inserite il vostro nome utente nel wiki e, come password, il token personale. Il client accetta anche il token come nome utente con password vuota.

Per la conservazione permanente usate l'assistente per le credenziali del vostro client. Non scrivete il token nell'indirizzo in .git/config.

Chi ha un livello da 4 a 7 può spostare solo rami sotto il proprio prefisso refs/heads/users/<login>/.

git push origin HEAD:refs/heads/users/mrossi/correzione

Un comando che tocchi qualcosa fuori da quel prefisso viene rifiutato per intero. Al livello 8 la restrizione non si applica.

Il pulsante Scarica come ZIP sul pannello Come ottenere questo repository scarica un'istantanea del ramo mostrato. L'indirizzo è /doku.php?do=wkdoadogit_archive&ns=<spazio-dei-nomi>&ref=<ramo> e richiede lo stesso livello 2 di clone.

• Verso Azure DevOps si presenta l'account di servizio. Il valore pushedBy è quindi l'account di servizio, mentre l'autore del commit resta la persona che lo ha creato.
• La revoca di un permesso vale dalla richiesta successiva. I permessi non vengono messi in cache. Se l'accesso persiste, cercate la cache delle pagine o un gruppo concesso, non il proxy.
• Il proxy non conosce l'innalzamento dell'autenticazione. Funziona senza sessione e si autentica a ogni richiesta con il token, perciò il secondo fattore si richiede al rilascio del token e non a ogni richiesta.
• Il server deve consentire PATH_INFO. Su Apache se ne occupa il file .htaccess fornito, con la riga AcceptPathInfo On per git.php. Il file web.config fornito vale solo per IIS. Senza di ciò il server risponde 404 prima ancora che PHP si avvii.
• La compressione lungo il percorso rovina il packfile. Non attivate gzip per il percorso del proxy.

• Guida: quando il token personale non serve
• Come modificare un file ed eseguire il commit dal wiki – modificare un singolo file senza client git
• Riferimento tecnico: livello di visibilità – quale livello concede quale capacità
• Diagnostica – gli errori 401, 403 e 404 presso il proxy