Problema con repo wiki.noiopen.it

Ciao @msciab,
oggi volevo iniziare ad integrare il mio lavoro con keycloak con il tuo wiki. Ho forkato su github ed ho provato a ricrearmi l’ambiente di development. Sembra andare tutto bene tranne per il fatto che il wiki non mi funziona. Ti ho aperto una issue che puoi vedere al link:

https://github.com/noiopen/wiki.noiopen.it/issues/1

Ho provato a clonare anche direttamente il tuo progetto su due macchine, il mio portatile (ubuntu 20) ed il mio vps (debian 10) e su entrambe ho lo stesso errore.

Senza il wiki funzionante in un ambiente di test, non so come lavorarci per integrare la sso e testarla.

Nel frattempo cerco di migrare quello che ho fatto con script in .sh a docker compose per il mio keycloak.

verifico e ti dico ma ho un sospetto…
dopo make restore ci sono i file sotto ./data? e soprattutto… chu uid hanno? dovrebbe essere 1000…

Ho eliminato tutto e ripartito con il git clone ed il make restore.
Dopo questi due comandi, ho una cartella data con dentro i seguenti file:

pciuffet@dellciuffetti:~/Projects/wiki.noiopen.it/data$ ls -lahn
total 1,6M
drwxrwxr-x 2 1000 1000 4,0K dic  5 14:31 .
drwxrwxr-x 6 1000 1000 4,0K dic  5 14:30 ..
-rw-rw-r-- 1 1000 1000    2 dic  5 14:30 .gitignore
-rw-rw-r-- 1 1000 1000  12K dic  5 14:31 noiopen_jobqueue.sqlite
-rw-rw-r-- 1 1000 1000  12K dic  5 14:31 noiopen_l10n_cache.sqlite
-rw-rw-r-- 1 1000 1000 1,5M dic  5 14:31 noiopen.sqlite
-rw-rw-r-- 1 1000 1000    0 dic  5 14:31 wikicache.sqlite

Come vedi, l’uid è quello del mio utente (pciuffet) con ID 1000

Ho appena provato. Sul mac funziona ma su Linux ho replicato l’errore.
Cerco di capire perchè… anche se temo di saperlo. Ora ti dico.

Ho risolto.
Quando lanci make up, lui lancia docker-compose up, che fa un build senza passargli il parametro dell’UID. Nel tuo Dockerfile impostavi un UID di default a 999, quindi il container partiva con l’utente con ID 999 e non riusciva a scrivere sul DB.

Levando la prima riga del Dockerfile dove definivi questo UID standard e lanciando:

make restore
make build
make up

Allora tutto funziona, perchè nel make build lanci il docker-compose build con il giusto argomento inizializzato nel Makefile.

Levando solo la prima riga del Dockerfile non si risolveva, quindi credo che il problema sia sul comando docker-compose up senza aver fatto prima la build con l’argomento UID passato come parametro.

Se vuoi ti faccio una pull request, o se hai capito puoi farlo direttamente tu :slight_smile:

ESATTO!
È quello che ho appena fatto io, temo che sia così per la build che ho fatto nella macchina di produzione.

Lascia stare le PR per ora avrei problemi con i backup se la mergio perchè la push che faccio per backuppare fallirebe

Lavora al keycloak e poi facciamo una PR unica quando lo installo.

Nota: aggiungi $wgOverrideHostname = "http://il.tuo.host:8080"; altrimenti ad ogni link ti aggiunge wiki.noiopen.it che è scritto nel database.

Ho appena scoperto che nel Makefile avevi creato un target dev che appunto faceva build e up :sweat_smile: ma nel wiki non era scritto. Sul mio fork ho sistemato il README.md, ho aggiunto un target clean nel Makefile che elimina i container creati ed ho aggiunto nel docker-compose il keycloak configurato a dovere. Mi manca solo la parte di integrazione tra MediaWiki e Keycloak. Ho trovato una guida ed appena posso provo e ti aggiorno.

ehm… fai pure delle pr per queste cose…

Ok. Ho avuto problemi nel far parlare MediaWiki e Keycloak in due container distinti (problemi di connessione tra container) che oggi pomeriggio dovrei aver capito come risolvere… anche perché se ti faccio una pr con il docker di Keycloak che però non parla con MediaWiki mi pare poco utile :sweat_smile: comunque se entro stasera risolvo committo sul mio repo e faccio la pr, altrimenti ti faccio una pr solo sulla parte MediaWiki (levando la parte Keycloak)

Ciao @msciab,
Intanto ho ripulito il mio lavoro e ti ho sottomesso una PR per il fix del readme per ricreare l’ambiente di sviluppo.

Ora ho un problema con il tuo consiglio sull’uso della variabile $wgOverrideHostname = "http://il.tuo.host:8080"; (nel mio caso, http://localhost:8080), in quanto la variabile wgServer sembra vincere.

Modificando il LocalSettings.php in questo modo:

#$wgServer = "https://wiki.noiopen.it";
$wgServer = WebRequest::detectServer();

mi funziona sia in localhost che sul mio vps http://imoas83.it:8080.

Come pensi debba procedere? Ti faccio una nuova pull request su questo cambiamento o pensi rompa qualcosa in produzione?

Se segui link locali a me funziona, non funziona se clicci un link esterno e finisci sul wiki ufficiale… da cui non torni indietro.

Io ho provato a fare le seguenti operazioni:

  • git clone
  • make restore
  • make dev
  • aggiungere la seguente riga a fine LocalSettings.php:
wgOverrideHostname = "http://localhost:8080";
  • lanciato make dev ed aperto un browser su http://localhost:8080

La pagina che mi si apre è https://wiki.noiopen.it/wiki/Pagina_principale

Se invece elimino la riga appena aggiunta e modifico la variabile wgServer come ti dicevo nel post precedente, allora tutto funziona senza problemi.

Suggerimenti?

No e’ giusto cosi, il redirect e’ cablato. Entra in localhost/wiki/Pagina_Principale

Ciao @msciab,
Per l’autenticazione via Keycloak avevo problemi con solo l’override dell’hostname, quindi nella mia copia locale sto usando la configurazione che mi funziona meglio.

A proposito di questo, avevo trovato due soluzioni per integrare keycloak con mediawiki:

  • quella descritta da questo articolo: MediaWiki and OAuth2 che mi ha funzionato in parte. Nello specifico, la logout non funziona correttamente (si resta loggati su keycloak) ed i tasti registrati e accedi non spariscono (per disabilitare la login locale);
  • quella ufficiale, usando l’estensione OpenID Connect;

Questa seconda mi ha fatto tribolare un po’ finchè non ho capito che non è compatibile con DB sqlite che usi al momento, ma solo con mysql o postgre. Difatti, quando provo a lanciare l’update.php come richiesto dall’estensione, non riesce ad eseguirla in quanto sqlite non è supportato.

Allora ho provato a lanciare a mano la query per creare la tabella che l’estensione voleva (prendendola dal file per il db mysql) e non riesce a creare l’indice (giustamente)…

Ma qui ho scoperto una cosa potenzialmente pericolosissima al momento: stavo vedendo se funzionava lo stesso senza la creazione dell’indice, quando ho notato che nel db noiopen.sqlite che è presente nel repo git pubblico c’è la tabella user giustamente riempita con gli utenti iscritti al wiki…con le hash delle password! Disponibili sul web!

Non sono un esperto di sicurezza ma ti consiglierei di rimuovere subito il backup dal repo pubblico ed avvisare gli iscritti al wiki che gli hash delle loro password sono state esposte sul web, magari le persone usano la stessa password per più account…

Detto ciò, a parte la falla di sicurezza, non posso procedere se non migriamo il db ad uno di quelli supportati o non si chiede a chi ha realizzato l’estensione OpenID Connect di implementare il supporto su sqlite. La prima soluzione che avevo trovato usa una libreria di una società privata e non so neanche se è manutenuta, quindi eviterei.

lo so. lo so benissimo. sono stato due ore a pensarci a cosa fare. poi ho pensato che le password sono di un sito a registrazione pubblica e quindi non rendono la cosa piu insicura di quello che gia è, certo se uno usa una password preziosa per g]registrarsi a un sito pubblico… ma comunque le password sono hashed. io volevo un backup di tutto, potrei rimuovere gli utenti prima di fareil backup… se vuoi pensarci una pr è benvenuta

Possiamo pensare ad una soluzione alternativa su dove salvare i backup, in modo da non metterli nel repo pubblico. In più, migrare il SQLite su MySQL (altro docker) così da poter integrare in un unico db i dati del wiki e del Keycloak e salvare quello, con gli utenti salvati in privato… in più, potremmo usare la libreria OpenID Connect di MediaWiki per l’autenticazione… Domani faccio delle prove, ma anche se hashate non lascerei le password a disposizione su web.

troppa carne al fuoco… per evitare problemi basterebbe uno script che rimuove gli utenti dal backup prima di committarlo su github

Per risolvere il problema attuale delle password si. Ma per l’integrazione con Keycloak mi serve comunque che il db sia MySQL o Postgresql che servirebbe sia MediaWiki che Keycloak. Così almeno ho letto sulle documentazioni per la messa in produzione di entrambi… faccio delle prove sul mio repo locale se ci riesco domani.

Capisco. Beh non e’ difficile installare il wiki in mysql ma tieni presente che l’installazione e’ manuale, io ho fatto l’ installazione a mano, ho backuppato il database e quindi dovresti fare lo stesso e poi fare una roba che starta mysql e inizializza il database. Classici problemi da devopos…

Il problema è la migrazione del db attuale da SQLite a MySQL (cercavo di non perdere le pagine, le revisioni, etc). Ho trovato un paio di guide ma non funziona mai bene.

Credo che farò una nuova installazione pulita senza migrare i dati (per ora) per vedere se riesco a fare sta benedetta integrazione con Keycloak in maniera pulita… ci ho praticamente lavorato tutto il weekend e sto un po’ fuso con le cose nuove che ho dovuto studiare :sweat_smile: