LINUX.ORG.RU
ФорумTalks

Google API и приватность

 


0

1

Хотел сделать небольшую утилитку, которая бы в качестве бекэнда использовала гугл таблицы (задача by design не предполагает больше пары сотен строк данных, но хочется чтобы данные были одни и те же у пользователя на разных устройствах, плюс юзер сохранит доступ к данным, если с приложением что-то случится, плюс удобно отлаживать).

Google API использует OAuth2 с короткоживущими токенами. Вроде секурно. Но мы также знаем, что когда токены живут мало, обычно есть refresh токены для получения новых без повторной авторизации.

Читаем доку: https://developers.google.com/identity/oauth2/web/guides/use-token-model?hl=en

By design, access tokens have a short lifetime. If the access token expires prior to the end of the user's session, obtain a new token by calling requestAccessToken() from a user-driven event such as a button press.

И «a user-driven event such as a button press» здесь не случайно. При вызове requestAccessToken, если юзер уже залогинен, то всё равно появляется всплывающее окно (которое заблокирует браузер, если оно появляется не в ответ на user-driven event), просто оно само и исчезает, если юзер уже авторизовался, выбрал учётку и дал доступ нашему приложению.

При этом в самой клиентской библиотеке отсутствует обработка ошибки протухшего токена, нужно руками её ловить и вызывать requestAccessToken.

При этом в Google API SDK для сервера таких проблем нет. Там есть refresh token и SDK автоматически обновляет токен при любом запросе API, который завершился неудачно из-за протухшего токена.

То есть получается:

Максимальное уважающее приватность пользователя приложения (автор не имеет технической возможности получить доступ к данным пользователя, доступ к данным имеет только само устройство пользователя и Google) будет выкидывать popup каждые несколько минут, а автор будет вынужден по всему коду распихивать костыли для обработки ошибок протухания токена.

Google заставляет разработчиков писать приложения хранящие токены доступа на своём бекэнде и иметь техническую возможность что-нибудь тихо и незаметно делать от имени пользователя. Всякие Firebase, хоть и позволяют не держать собственный бекэнд, всё равно позволяют разработчику иметь доступ к данным пользователя.

Или я не осилил их Identity Services?

★★★★★

Последнее исправление: KivApple (всего исправлений: 2)

Думать о прайвайси и заставлять пользователей своего приложения пользоваться гуглосервисами это двоемыслие какое-то

cobold ★★★★★
()

… Максимальное уважающее приватность пользователя приложения (автор не имеет технической возможности получить доступ к данным пользователя, доступ к данным имеет только само устройство пользователя и Google) будет выкидывать popup каждые несколько минут, а автор будет вынужден по всему коду распихивать костыли для обработки ошибок протухания токена.

Это можно рассматривать как нелогичность и неудобство в случае локально установленного приложения, поскольку пользователь в этом случае заведомо сам контролирует удаление приложения и всех его локальных настроек и данных со своего компа. В том числе, и удаление refresh-токена.

В случае веб-приложения у нас нет прямой возможности удалить приложение. Чистка кэша и прочих данных веб-обозревателя - это уж очень кардинальный способ для завершения работы с одним веб-приложением и далеко не у каждого руки дойдут до выполнения такого действия. Соответственно, вступает в силу другое, более приоритетное соображение - вообще не хранить в клиентской среде веб-приложения (например, в Web Storage) какие-то постоянно действующие секретные данные. Иначе пользователи, в силу своего разгильдяйства, будут оставлять эти данные в разных местах на компах общего пользования.

Видимо, исходя из подобных соображений гуглы и убрали возврат refresh-токена из клиентской библиотеки SDK для веб-обозревателя. Хранить refresh-токены каких-то личных постоянных аккаунтов в среде сторонних серверов - это тоже по своей сути неправильно, и лучше такие приложения не создавать.

vinvlad ★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)