2012-04-21 11 views
9

Od włączenia uwierzytelniania 2-czynnikowego (alias weryfikacji dwuetapowej) w Google moja wersja Google export scripts przestanie działać. Komputer jest zweryfikowany i zaufany, ale w jakiś sposób nie są to skrypty. W efekcie za każdym razem, gdy uruchamiane jest zadanie cron, otrzymuję nowy "kod weryfikacyjny Google" i skrypt nie działa. Zakładam, że powinno być proste uwierzytelnianie takich skryptów raz na zawsze z wget lub curl, ale nie mogłem znaleźć żadnej dokumentacji, jak to zrobić.Jak używać hasła aplikacji Google w skrypcie?


systemy uwierzytelniania Google przeszły wielu iteracji, i już nie mogę wydają się zalogować używając curl lub mechanicalsoup. Próbowałem używać adresów URL takich jak https://accounts.google.com/ServiceLogin?continue=https://calendar.google.com/calendar/exporticalzip&[email protected]&Passwd=application-specific-password, a zawsze przekierowywano mnie na stronę logowania, zwykle z komunikatem "Użyj hasła do konta zamiast hasła specyficznego dla aplikacji".

+2

należy spróbować użyć OAuth2 zamiast tego starego przestarzałej podejście, to nie ma mniej kłopotów z tokenów weryfikacji. – Tim

+0

@Tim: Czy istnieje przewodnik, jak z niego korzystać ze skryptami powłoki? – l0b0

+0

Specyfikacja na http://tools.ietf.org/html/draft-ietf-oauth-v2-25 pokazuje, jak to zrobić. Myślę, że 'curl' może być w stanie zrobić coś z https i pozwolić ci przekazywać żądania z' --raw'? A może curl ma opcje dopasowania tego typu rzeczy? – ams

Odpowiedz

0
+0

Nie mogę wymyślić, jak to zrobić ze skryptu powłoki. A * lot * googling nie odkrył pojedynczego skryptu powłoki, który wydaje się być zdolny do weryfikacji dwuetapowej. – l0b0

+0

Sprawdź linki - jest to weryfikacja jednoetapowa z użyciem losowo wygenerowanego hasła, przeznaczona specjalnie dla aplikacji, które są niezgodne z weryfikacją dwuetapową. – Tgr

+0

"Jeśli jesteś programistą Google Apps API i korzystasz z uwierzytelniania ClientLogin" - nie wiem, o ile mi wiadomo - [skrypt uwierzytelniający] (https://github.com/l0b0/export/blob/master/GoogleAuth .sh) używa 'ServiceLoginAuth', a zwykłe zastąpienie hasła hasłem specyficznym dla aplikacji nie działa. – l0b0

0

Tworzenie haseł aplikacji działa dla moich skryptów, wszystko co robisz, to tworzenie hasła, a następnie w skrypcie, gdzie zamiast tego masz hasło do konta google.

Zobacz tutaj po więcej na wniosek poszczególnych haseł:

Application Specific Passwords

Nadzieja to pomaga !!

+0

Wypróbowałem już i nie zaakceptowałem żądania. Czy masz rzeczywisty przykład kodu? – l0b0

4

Czy jesteś absolutnie pewien, że chcesz używać 2-czynnikowego auth w skryptach powłoki? Jeśli tak, nie musisz starać się, aby twój komputer lub skrypt był "zaufany". Po uruchomieniu skryptu wystarczy wykonać pełne 2-czynnikowe uwierzytelnienie.

Jeśli celem jest pominięcie ręcznego auth drugiego czynnika, sugeruję użycie hasła specyficznego dla aplikacji (jak już sugerowały inne odpowiedzi). Po prostu udawaj, że nie używasz 2-czynnikowego auth w ogóle i używaj prawdziwej nazwy logowania, ale ustaw hasło do tego wygenerowanego pod numerem https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en (podstrona od https://www.google.com/settings/security).

Celem jest ustawienie hasła specyficznego dla aplikacji "Nazwa" na wartość, która ma dla Ciebie znaczenie. Na przykład mam hasła oznaczone jako "Pidgin w pracy", "Mój telefon z Androidem", "Rozszerzenie książki adresowej Google Thunderbird w pracy" itp. Możesz mieć hasło "Skrypt eksportu kalendarza i czytnika". Jeśli kiedykolwiek uwierzysz, że to hasło specyficzne dla aplikacji jest zagrożone ("wyciekło"), po prostu kliknij link "Odwołaj" na tej samej stronie, a następnie wygeneruj nowe hasło do skryptu.

Dla kodu wystarczy użyć ostatniej wersji, która działała z auth Auth. Aktualizacja:, ponieważ pierwotne pytanie użyte w adresie URL https://accounts.google.com/ServiceLogin do inicjowania logowania do sesji jest praktycznie sfałszowanym loginem do przeglądarki. Jednak Google oficjalnie nie wspiera tego i kiedy to piszę, wydaje się, że użycie hasła specyficznego dla aplikacji do normalnego logowania zakończy się komunikatem o błędzie "Użyj hasła do konta zamiast hasła specyficznego dla aplikacji".

Jedną z rzeczy, które należy zrozumieć w przypadku 2-czynnikowego uwierzytelnienia Google i "zaufanego komputera", jest to, że rzeczywista implementacja dodaje do przeglądarki stały plik cookie z 30-dniowym okresem wygaśnięcia. Zaufany komputer nie oznacza, że ​​twój adres IP był zaufany lub zostało utworzone inne magiczne połączenie. Jeśli twoje skrypty nie przechwycą pliku cookie "zaufanego komputera" z wybranej przeglądarki, nie ma znaczenia, czy kiedykolwiek oznaczałeś komputer jako zaufany.(Formularz Google nie powinien zawierać słów "Zapamiętaj ten komputer przez 30 dni", ale "Zaufaj tej kombinacji przeglądarki i konta użytkownika przez 30 dni (zachowaj stały plik cookie)". Sądzę jednak, że uznano to za zbyt techniczne ...)

Aktualizacja: (skopiowano z mojego komentarza poniżej) Jedynie oficjalnie obsługiwana metoda (aplikacje Server to Server) jest udokumentowana pod numerem https://developers.google.com/accounts/docs/OAuth2ServiceAccount. Wymaga kodowania żądania OAuth/JWT i używania klucza prywatnego konta usługi utworzonego pod numerem https://code.google.com/apis/console. Alternatywnie można użyć uwierzytelniania ClientLogin (już uznanego za nieaktualny i do 2015 roku).

Jeśli zdecydujesz się pójść z OAuth, warto spojrzeć na http://blog.yjl.im/2010/05/bash-oauth.html i https://github.com/oxys-net/curl-oauth

+0

Komunikat o błędzie "Użyj hasła do konta zamiast hasła specyficznego dla aplikacji." Wygląda na to, że google aktywnie zabija wszelką obsługę zwykłego logowania do hasła po aktywowaniu logowania 2-czynnikowego. Jedyna oficjalnie obsługiwana metoda (aplikacje Server to Server) jest udokumentowana na https://developers.google.com/accounts/docs/OAuth2ServiceAccount. Wymaga kodowania żądania OAuth/JWT i używania klucza prywatnego konta usługi utworzonego pod adresem https://code.google.com/apis/console/. Alternatywnie można użyć uwierzytelniania ClientLogin (usługa "best effort" do 2015 r.). –

+1

Jeśli zdecydujesz się skorzystać z protokołu OAuth, możesz przejrzeć http://blog.yjl.im/2010/05/bash-oauth.html i https://github.com/oxys-net/curl-oauth –

+0

To już nie działa, więc szukam innego rozwiązania ... – l0b0

Powiązane problemy