Sei assolutamente sicuro di voler utilizzare l'autenticazione a 2 fattori con gli script della shell? Se è così, non è necessario cercare di ottenere il tuo computer o script come "fidato". Basta eseguire l'autenticazione a 2 fattori ogni volta che si esegue lo script.
Se l'obiettivo è saltare l'autenticazione manuale del secondo fattore, suggerirei invece di utilizzare una password specifica dell'applicazione (come già suggerito da altre risposte). Fai finta di non utilizzare l'autenticazione a 2 fattori su tutto e utilizzare il tuo nome di accesso reale, ma imposta la password a una generata a https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en (sottopagina di https://www.google.com/settings/security).
L'intento è quello di impostare la password specifica dell'applicazione "Nome" su un valore che è significativo per voi. Ad esempio, ho delle password con l'etichetta "Pidgin at work", "My Android Phone", "Thunderbird Google Address Book Extension at Work" ecc. Si può avere una per "Calendar and Reader Export Script". Se credi che questa password specifica per l'Applicazione sia compromessa ("trapelata"), basta cliccare sul link "Revoca" nella stessa pagina e quindi generare una nuova password per il tuo script.
Per il codice, utilizzare solo l'ultima versione che ha funzionato con Google fattore singolo auth. Aggiornamento: poiché la domanda originale utilizzava l'URL https://accounts.google.com/ServiceLogin
per avviare l'accesso alla sessione è praticamente falso l'accesso al browser. Tuttavia, Google non supporta ufficialmente questo aspetto e, mentre sto scrivendo questo, sembra che l'utilizzo di una password specifica per l'applicazione per l'accesso normale finirà con il messaggio di errore "Utilizzare la password dell'account anziché una password specifica per l'applicazione".
Una cosa da capire sull'autenticazione a 2 fattori di Google e sul "computer fidato" è che l'implementazione effettiva aggiunge semplicemente un cookie permanente con 30 giorni di scadenza al browser. Il computer fidato non significa che il tuo indirizzo IP sia affidabile o che siano state create altre connessioni magiche. A meno che i tuoi script non catturino il cookie "trusted computer" dal tuo browser preferito, non importa se hai mai contrassegnato il tuo computer come affidabile.(Il modulo di Google non dovrebbe dire "Ricorda questo computer per 30 giorni" ma "Fidati di questo browser e combinazione di account utente per 30 giorni (salva cookie permanente)". Tuttavia, immagino che sia stato considerato troppo tecnico ...)
Aggiornamento: (copiato dal mio commento in basso) L'unico metodo ufficialmente supportato (applicazioni Server to Server) è documentato allo https://developers.google.com/accounts/docs/OAuth2ServiceAccount. Richiede la codifica OAuth/JWT della richiesta e l'utilizzo della chiave privata dell'account di servizio creata a https://code.google.com/apis/console. In alternativa è possibile utilizzare l'autenticazione ClientLogin (già deprecato, miglior sforzo fino al 2015).
Se si decide di andare con OAuth, si potrebbe desiderare di guardare http://blog.yjl.im/2010/05/bash-oauth.html e https://github.com/oxys-net/curl-oauth
fonte
2012-07-09 05:57:00
Si dovrebbe provare a utilizzare OAuth2 piuttosto che questo vecchio metodo deprecato, quindi c'è meno problemi con i token di verifica. – Tim
@Tim: Esiste una guida su come utilizzarlo con lo script di shell? – l0b0
Le specifiche su http://tools.ietf.org/html/draft-ietf-oauth-v2-25 mostrano come farlo. Penso che 'curl' potrebbe essere in grado di fare il materiale https e lasciarti passare le richieste con' --raw'? O forse il ricciolo ha opzioni per adattarsi a questo genere di cose? – ams