Uno script salva ogni mattina una bozza su WordPress. Quando smetti di usarlo, puoi togliergli accesso senza cambiare la password con cui entri nella bacheca? Con le password applicative WordPress puoi assegnare una credenziale al singolo programma e revocarla quando serve. La separazione funziona se sai a quale utente appartiene, quali azioni può eseguire e dove sostituirla.
Prendiamo il caso di una redazione che riceve bozze da uno script e le pubblica dopo la revisione. Il percorso parte dal ruolo WordPress, passa per una richiesta API in sola lettura e arriva alla prova di revoca. Lo stesso metodo vale per un gestionale o un altro servizio che deve operare sul sito.
Come funzionano le password applicative WordPress
Una password applicativa è un segreto generato per un utente WordPress. Il programma la usa insieme al nome utente per autenticarsi tramite la REST API. Può funzionare anche con XML-RPC, se disponibile e supportato dal programma. La password applicativa non consente di entrare dalla schermata di login di WordPress. Usa sempre HTTPS, perché con autenticazione Basic la protezione dei dati durante il transito dipende dalla connessione cifrata.
Puoi creare più password per lo stesso utente e assegnare un nome a ciascuna. Se lo script redazionale e un servizio di sincronizzazione usano credenziali diverse, puoi spegnere il primo senza interrompere il secondo. Entrambe le credenziali operano però con i permessi del rispettivo utente. Se appartengono allo stesso account, i nomi aiutano a riconoscerle, ma non limitano le operazioni consentite.
Per le persone restano valide le misure descritte nella guida per proteggere le password online. Un programma ha esigenze diverse: deve poter leggere il proprio segreto durante il lavoro e nessuno deve copiarlo nelle note di redazione.
Scegliere il ruolo prima di creare la credenziale
Elenca le azioni che il programma deve compiere sul sito. Per la redazione servono due operazioni: salvare bozze proprie e aggiornare quelle già create. Se lo script non carica immagini e non pubblica, puoi partire da un utente dedicato con ruolo Collaboratore. Nella configurazione standard quel ruolo può scrivere e gestire i propri articoli senza pubblicarli. Il ruolo Autore può invece pubblicare i propri articoli e caricare file. Estensioni e ruoli personalizzati possono cambiare questi permessi: controlla sul sito in cui girerà lo script.
Una verifica utile consiste nel prendere una bozza creata a mano e chiedersi se il programma debba modificarla. Se la risposta è no, tieni distinto il lavoro automatico da quello dei redattori. Se la risposta è sì, decidi quali bozze devono rientrare nel flusso e verifica i permessi sul caso concreto. Un account amministratore usato per superare un errore di permessi può dare al programma accesso a funzioni che non gli servono.
Usa credenziali distinte anche tra ambiente di prova e sito pubblico. Un errore di configurazione nello script, per esempio un indirizzo rimasto nel file di test, è più facile da riconoscere quando ogni ambiente ha un proprio utente e una propria password applicativa.
Creare la password dal profilo utente
Nella bacheca apri Utenti > Profilo per il profilo con cui sei entrato, oppure apri la scheda del profilo dedicato se hai i permessi per gestirlo. Cerca Password delle applicazioni, assegna un nome leggibile e aggiungi la credenziale. Per lo script di esempio puoi usare Redazione | Import bozze | Produzione. Un nome così ti aiuta a ritrovare la voce quando arriva il momento di sostituirla.
WordPress mostra il valore completo una sola volta, alla creazione. Salvalo subito nel gestore di segreti del servizio o nella configurazione protetta letta dal processo. Controlla che lo script pianificato possa leggere quel valore e che non finisca nel codice sorgente, nei log, nei ticket o nelle schermate di assistenza. Se chiudi la pagina prima di salvarlo, revoca la voce appena creata e genera una nuova credenziale.
Se la sezione manca, verifica che il sito usi HTTPS, che la versione di WordPress supporti la funzione e che la configurazione o un plugin non la disabilitino per quel profilo. Se il sito è dietro un proxy, chi lo gestisce può anche controllare che WordPress riconosca la richiesta come sicura.
Verificare accesso e permessi con due prove
Prima prova: riconoscere il profilo senza scrivere dati
Invia una richiesta GET al percorso /wp-json/wp/v2/users/me usando il nome utente e la password applicativa. Con curl, imposta WP_ENDPOINT al valore completo del tuo indirizzo HTTPS, terminando con il percorso indicato. Se usi Bash, puoi fare la prova così:
curl --user utente_integrazione --url "$WP_ENDPOINT"Sostituisci utente_integrazione con il nome usato per accedere. Curl chiede la password in modo interattivo, così il segreto resta fuori dal comando. Su Windows puoi richiamare curl.exe se il nome curl avvia un comando diverso. Nel risultato cerca il campo id e verifica che corrisponda al profilo dedicato. Una risposta positiva da una pagina pubblica non è una prova equivalente: quella pagina può rispondere anche senza credenziali.
Se la prova fallisce, controlla prima sito di destinazione, nome utente e credenziale selezionata. Se i dati sono corretti, verifica con chi gestisce il server se il proxy o le regole di sicurezza fanno arrivare a WordPress la richiesta e il campo Authorization. Per la diagnosi basta registrare lo stato HTTP e il codice di errore restituito, senza stampare il campo che contiene le credenziali.
Seconda prova: eseguire il lavoro previsto
Quando il profilo è quello giusto, fai creare allo script una bozza di prova, preferibilmente in un ambiente di test. Rileggila dalla bacheca e controlla autore e stato. Se lo script deve aggiornarla, chiedigli di riscrivere un campo e verifica il risultato sulla stessa bozza. Se deve anche inviare immagini, prova il caricamento separatamente: il salvataggio del testo non dimostra che il ruolo abbia accesso ai media.
Se il primo controllo riesce ma la scrittura viene rifiutata, esamina il ruolo e il permesso richiesto per la scrittura richiesta. Se invece lo script funziona a mano ma fallisce quando parte da solo, controlla quale utente di sistema lo avvia e da dove legge il segreto. Per capire dove si ferma, confronta il risultato di una esecuzione manuale con quello registrato dal compito pianificato.
Per uno script che importa articoli, conserva nel sistema sorgente un riferimento che colleghi ogni voce al relativo ID WordPress. Al prossimo passaggio potrai aggiornare la stessa bozza invece di crearne una nuova. Se il primo invio si interrompe prima che il programma riceva un ID, cerca la bozza sul sito prima di ripetere la richiesta. È un controllo utile anche durante il cambio di credenziale: puoi verificare il nuovo accesso aggiornando un elemento di prova già noto e controllare che il totale delle bozze resti lo stesso.
Sostituire o revocare una password applicativa
Sostituzione programmata: prova il nuovo accesso prima della revoca
Crea una seconda credenziale nello stesso profilo e salvala nella configurazione del servizio. Fai la prova in sola lettura, poi lascia eseguire allo script almeno un ciclo nel contesto in cui lavora di solito. Per la redazione significa osservare una vera esecuzione pianificata e verificare che la bozza arrivi con stato e autore corretti.
A quel punto revoca soltanto la vecchia voce dalla sezione delle password applicative. Verifica che il servizio continui a funzionare con la nuova configurazione. Se prima della revoca scopri che il programma legge ancora un vecchio file, puoi correggere il percorso mentre la credenziale precedente è attiva. Dopo la revoca non puoi riattivare quel valore: se serve ripristinare il collegamento, genera un altro segreto.
Sospetta esposizione: revoca subito
Se trovi la password in un repository, in un log condiviso o in un ticket, revoca subito la voce. La rimozione della riga dal file lascia aperto il rischio che il valore sia già stato copiato o sia presente nella cronologia. Se serve, sospendi il compito pianificato per evitare nuovi tentativi mentre sistemi la configurazione.
La revoca blocca le richieste successive con quella credenziale, ma non annulla eventuali modifiche già fatte. Controlla gli articoli, i media o gli altri dati che il profilo poteva toccare e confronta le attività con le esecuzioni attese. Genera una nuova password solo quando hai individuato e corretto il punto da cui usciva il segreto. Se più programmi usavano lo stesso valore, approfitta del ripristino per assegnarne uno a ciascuno.
Tenere un registro utile quando cambia il referente
Per ogni collegamento annota nome della credenziale, sito, profilo WordPress, servizio che la usa e persona responsabile. Indica dove si trova la configurazione protetta senza riportare il valore. Aggiungi il compito pianificato da fermare e la prova da ripetere dopo una sostituzione. Se la gestione passa a un webmaster, il registro gli permette di intervenire senza dover cercare la password nelle chat o chiedere quale script è ancora in uso.
Nel profilo WordPress puoi consultare il nome della credenziale e, quando presenti, i dati di ultimo utilizzo e ultimo IP. Sono indizi per ricostruire le attività. Per confermare che una prova appena eseguita sia riuscita, guarda la risposta della richiesta e il risultato del lavoro. Prima di revocare una voce che sembra inattiva, controlla se appartiene a un compito che parte solo a fine mese o su richiesta.
Per mettere ordine nelle password applicative WordPress, parti dal programma con i permessi più ampi. Verifica quale profilo usa, riduci le autorizzazioni a quelle necessarie e annota dove revocare la sua credenziale. Quando una password serve a un solo programma e sai come controllarlo dopo il cambio, puoi chiudere quel collegamento senza intervenire sugli altri.
