Вы абсолютно уверены, что хотите использовать двухфакторное аутентификационное письмо со сценариями оболочки? Если это так, вам не нужно пытаться заставить ваш компьютер или сценарий «доверять». Вы просто выполняете полный 2-факторный аут при каждом запуске скрипта.
Если цель состоит в том, чтобы пропустить ручной второй коэффициент auth, я бы предложил вместо этого использовать пароль для приложения (как уже было предложено другими ответами). Просто притворитесь, что вы не используете 2-факторное аутентификацию вообще и используете свое реальное имя для входа, но задаете пароль для одного, сгенерированного на https://accounts.google.com/b/0/IssuedAuthSubTokens?hl=en (подстраница https://www.google.com/settings/security).
Цель состоит в том, чтобы установить для конкретного приложения пароль «Имя» значение, имеющее для вас значение. Например, у меня есть пароли с надписью «Pidgin at work», «My Android Phone», «Расширение адресной книги Google Thunderbird» и т. Д. У вас может быть один для «Script and Reader Export Script». Если вы когда-либо считали, что этот пароль для конкретного приложения скомпрометирован («просочился»), просто нажмите ссылку «Отменить» на той же странице, а затем создайте новый пароль для своего скрипта.
Для кода просто используйте последнюю версию, которая работала с Google single factor auth. Обновление:, потому что исходный вопрос использовал URL-адрес https://accounts.google.com/ServiceLogin для запуска входа в сессию, это практически ошибка при входе в браузер. Однако Google официально не поддерживает это, и, поскольку я пишу это, кажется, что с использованием специального пароля для обычного входа в систему будет выведено сообщение об ошибке «Пожалуйста, используйте свой пароль учетной записи, а не пароль для конкретного приложения».
Одна вещь, чтобы понять, что Google 2-factor auth и «доверенный компьютер» состоит в том, что фактическая реализация просто добавляет постоянный файл cookie с истечением 30 дней в ваш браузер. Надежный компьютер не означает, что ваш IP-адрес был доверен или создано другое магическое соединение. Если ваши сценарии не захватывают cookie «доверенного компьютера» из вашего браузера, это не имеет значения, если вы когда-либо отмечали свой компьютер как доверенный.(Форма Google не должна указывать «Помните этот компьютер в течение 30 дней», но «доверяйте этой комбинации браузера и учетной записи пользователя в течение 30 дней (сохраняйте постоянный файл cookie)». Однако, я думаю, это считалось слишком техническим ...)
Обновление: (скопировано из моего комментария ниже) Единственный официально поддерживаемый метод (приложения Server to Server) документируется по адресу https://developers.google.com/accounts/docs/OAuth2ServiceAccount. Для этого требуется OAuth/JWT, кодирующая запрос, и использование закрытого ключа учетной записи службы, созданного по адресу https://code.google.com/apis/console. В качестве альтернативы вы можете использовать аутентификацию ClientLogin (уже устаревшее, лучшее обслуживание усилий до 2015 года).
Если вы решите пойти с OAuth, вы можете захотеть взглянуть на http://blog.yjl.im/2010/05/bash-oauth.html и https://github.com/oxys-net/curl-oauth
Вы должны попробовать использовать oauth2 вместо этого старого устаревшего подхода, то есть меньше хлопот с лексем проверки. – Tim
@Tim: Есть ли руководство по использованию этого скрипта? – l0b0
Спецификация на http://tools.ietf.org/html/draft-ietf-oauth-v2-25 показывает, как это сделать. Я думаю, что «завиток» мог бы сделать материал https и позволить вам передавать запросы с помощью «-raw»? Или, может быть, у завитка есть варианты для такого рода вещей? – ams