Секретен ли Client secret?

Насколько я понимаю, при наличии этого пароля можно делать все, что позволяет Contacts API гугла. Соответственно, возможный ущерб будет в этих рамках.

если да, то как я в принципе могу это сделать в программе, распространяемой по лицензии GPL?

А при чем здесь это?

Точно так же, как и в любой другой распространяемой программе. Ну то есть лишь не включая его туда.

Смысл oauth2 в том чтобы _сервис_ мог получить данные клиента от другого сервиса. Зачем oauth2 если это приложение?

Если oauth2 и предусматривает какие то такие случаи, то нужно понимать что ты делаешь и зачем, и как этого добиться.

Так это же не исходник? И вроде да, он должен быть секретным, поэтому нет большого смысла включать его в исходник.

Насколько я понимаю, при наличии этого пароля можно делать все, что позволяет Contacts API гугла. Соответственно, возможный ущерб будет в этих рамках.

Да собственно, исключительно в рамках аккаунта. Если пользователь авторизовался с аккаунтом X из моей программы, он может работать только со своей адресной книгой. При попытке залезть в книгу аккаунта Y он, естественно, получит ошибку (проверял).

Точно так же, как и в любой другой распространяемой программе. Ну то есть лишь не включая его туда.

Ага. Вот только если я его буду прикладывать в виде отдельного файла - он перестанет быть секретным.

Смысл oauth2 в том чтобы _сервис_ мог получить данные клиента от другого сервиса. Зачем oauth2 если это приложение?

Затем, что гугл (и вероятно, не только он) не даёт возможности скачать по сети адресную книгу без OAuth2. Вот, собственно, пример от разработчиков Qt, явно подразумевающий десктопное применение, есть русский перевод. (Только с примером в конце статьи они, на мой взгляд, накосячили, чтобы запрос работал, параметр access_token в него таки надо добавить вручную.)

Есть такая штука как implicit grant, но возможно есть еще более простой способ получить токен.

И да, у гугл апи (и не только гугл) оаутх2 это только про получение токена, остальное апи это просто апи.

И да, у гугл апи (и не только гугл) оаутх2 это только про получение токена, остальное апи это просто апи.

Я в курсе. Далее я просто скармливаю этот токен в нужные запросы, это я уже заставил работать. Интересно именно, как «идейно правильно» организовать получение токена - пока у меня все исходные данные берутся прямо из JSON, скачанного из гугла.

Есть такая штука как implicit grant

Ага! Спасибо за наводку. Почитал, очень вероятно, это именно то, что мне нужно.

В QtNetworkAuth на данный момент реализован Authorisation Code Grant. У реализующего его класса есть абстрактный предок, что вселяет надежду на реализацию и других методов. Но в конце концов можно поискать другую библиотеку или попробовать разобраться и написать свою.

Остаётся вопрос: а сам гугл-то мне позволит получить implicit grant для зарегистрированного в гугле приложения?

Точно так же, как и в любой другой распространяемой программе. Ну то есть лишь не включая его туда.

Ага. Вот только если я его буду прикладывать в виде отдельного файла - он перестанет быть секретным.

Само собой. Как только вы его передадите его кому бы ни было в любом пригодном для использования по назначению виде, он перестанет быть секретным.

Какая разница, файл—не файл, исходник—не исходник?

должен ли я хранить этот самый Client secret в тайне, на что намекает его название, или без доступа к моему аккаунту никакого ущерба для безопасности это не несёт?

Так ты хочешь дать доступ к своей адресной книге или адресной книге клиента? Если к своей, то публикуй, а если к клиента, то клиент должен получить свой Client secret. Тогда просто делаешь его параметром и запрашиваешь у клиента.

Client secret

секрет - это же выделение, типа пота

Я так понял, что клиентом ты называешь пользователя программы. Тут же, насколько я понимаю, немного не про то.

Я регистрирую своё приложение в Google Developer Console. И на приложение гугл выдаёт Client ID и Client Secret. На приложение, не на пользователя.

Я регистрирую своё приложение в Google Developer Console. И на приложение гугл выдаёт Client ID и Client Secret. На приложение, не на пользователя.

На самом деле как бы на пользователя. В смысле того, кто эту программу будет привязывать к своей учётке.

Вот, собственно, пример от разработчиков Qt, явно подразумевающий десктопное применение

Цитата оттуда:

Different options are available here; you need to choose “Web application”. Give it a name.

...

Add a URI accessible by your Internet browser including the port if you are using a different one than 80. When the application is running, a basic HTTP server will receive information from the browser.

Most of the times you need to use a URI like: “http://localhost:8080/cb”.

NOTE: The path “/cb” is mandatory in the current QOAuthHttpServerReplyHandler implementation.

---------------------

То есть делаем сами себе «сайт» и с ним работаем.

если да, то как я в принципе могу это сделать в программе, распространяемой по лицензии GPL?

Никак все эти облачные ключи в принципе не совместимы с открытым кодом

P.S. рекаптча должна умереть

Никак[, ибо] все эти облачные ключи в принципе не совместимы с открытым кодом

Можно чуть поподробнее? Что здесь такое «открытый код»?

То есть делаем сами себе «сайт» и с ним работаем.

Это же про вторую часть авторизации. Гугл от нас получил Redirect URI и обращается к нему. Кстати, это как раз то, что поломали в Qt 5.10 (в 5.8 работало, и ещё я не успел проверить новейшую 5.10.1).

Как это относится к проблеме Client Secret (который всё равно отправляется гуглу на первом этапе), я не понял.

На самом деле как бы на пользователя. В смысле того, кто эту программу будет привязывать к своей учётке.

Я правильно понял, что ты предлагаешь каждому пользователю моей программы лезть в Google Developer Console и создавать там свою учётную запись для моего приложения?

Да, чисто технически это решит проблему. Можно даже в программе предусмотреть динамическую подгрузку параметров соединения из JSON-файла, который генерирует гугл.

Но как-то, по-моему, по отношению к самому пользователю это совсем не гуманно. Да и идейно как-то неправильно заставлять пользователя лезть в инструмент для разработчиков, создавать аккаунт для чужой программы, API какие-то подключать...

Почитай про oauth2. По сути мулька в том что clientid и clientsecret ты никуда отдавать не должен а жить они должны у тебя на серваке, вместе с сервисом, который и ходит за контактими юзера в гугл. Для чего юзер и авторизуется в гугле отдавая тебе свой токен.

Спасибо, но увы - ещё один невнимательно прочитал ОП и, видимо, совсем не читал комментариев. Ещё раз: специфика моего случая в том, что у меня нет никакого сервиса. У меня десктопное приложение, которое вынуждено выступать в качестве клиента OAuth2. В Qt есть набор классов, специально заточенный под эту ситуацию, и есть сторонние библиотеки. И в принципе, я уже заставил это работать.

Вопрос в том, как правильно организовать для них исходные данные.

Пока что основная надежда на Implicit grant, я так понял, он как раз для таких случаев, где засекретить ничего нельзя - но похоже, реализовывать его придётся самому.

увы - ещё один невнимательно прочитал ОП

Увы кое-кто не понял ответа и не прочитал для чего нужен оаут или хотя бы пример из культей.

Да implicit grant придумали на подобный случай. Но твои клиентид и клентсекрет ты всё равно никому ни в каком виде не отдаешь.

Я правильно понял, что ты предлагаешь каждому пользователю моей программы лезть в Google Developer Console и создавать там свою учётную запись для моего приложения?

Да.

https://infostart.ru/public/174240/

https://yellow-erp.com/2013/11/simple-twitter-client-for-1c-8-3/

Но как-то, по-моему, по отношению к самому пользователю это совсем не гуманно. Да и идейно как-то неправильно заставлять пользователя лезть в инструмент для разработчиков, создавать аккаунт для чужой программы, API какие-то подключать...

Это гугл... Альтернатива — поднимать свой сервер авторизации в Интернете. Ну или забить на безопасность: сделать отдельную учётку гугла чисто под программу и выложить её коды.

Но твои клиентид и клентсекрет ты всё равно никому ни в каком виде не отдаешь.

Они должны быть в исходниках программы, чтобы программа работала. Если программа под GPL. то придётся отдавать. Или не писать их в коде программы, а запрашивать у клиента.

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

причём гугл урезает и урезает все эти API и доступы год от года. есть у них такая тенденция.

Ну да, никто не запрещает отдавать эти данные просто логика оаута в гугле подразумевает что ими рулит таки владелец девелоперского акка.

Похоже что таки запрещает

https://developers.google.com/terms/

Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects.

просто логика оаута в гугле подразумевает что ими рулит таки владелец девелоперского акка.

Так с этим никто и не спорит :)

О! Спасибо, анонимус! Это один из наиболее полезных комментариев в треде, наряду с упоминанием redixin про implicit grant.

хотела сделать нормальный консольный клиент

На консольный я вот тоже сначала хотел рыпнуться, тем более, что у меня в проекте, кроме гуёвого приложения, предусмотрен ещё и консольный конвертер форматов на той же кодовой базе. Но потом прочитал про авторизацию через браузер и понял, что всё плохо. Хотя вот в прошлой теме тов. RazrFalcon предлагал токен из браузера руками копировать - такое решение, возможно, для консольной программы вполне прокатит.

причём гугл урезает и урезает все эти API и доступы год от года. есть у них такая тенденция.

Он не то, чтобы урезает, скорее, заменяет стандартные решения на свои велосипеды. Почему-то к CardDAV мне даже с OAuth подключиться уже не удалось (хотя здесь, возможно, я накосячил), пришлось считывать контакты через Contacts API, и уже не факт, что оно без потерь однозначно отобразится на структуру полей vCard. Жизнь боль, короче. :)

Увы кое-кто не понял ответа и не прочитал для чего нужен оаут или хотя бы пример из культей.

Кстати, о примере из культей - там в комментариях Хесусу задавали вопрос, аналогичный моему, и Хесус признал, что это проблема, к которой он не знает удовлетворительного решения. Про implicit grant, правда, речь не заходила.

Альтернатива — поднимать свой сервер авторизации в Интернете.

Вот так и рождаются всякие тимвьюверы. :)

Идея в том, что гугл проектировал это API не думая, что им может пользоваться десктопное приложение, только веб-сервисы. А там код на серверной части юзер не контролирует и держать там токен не является проблемой (в случае публикации серверного кода в OpenSource secret key является одной из настроек, которую должен ввести владелец сервера при установке приложения - заставить его лазить в консоль гугла нормально).

С точки зрения гугла правильнее всего было бы проксировать запросы к календарю через свой сервер. Ну или хотя бы проксировать авторизацию (если secret key нужен только неё). Поскольку Google любит зонды, то он предполагает, что у юзера к ним уже развита достаточная толерантность, чтобы доверить свои данные другим веб-серверам. Как компромисс, можно сделать настройку - если юзер предоставит свой secret key, то приложение работает напрямую с гуглом, если ему лень - через твой сервер.

С другой стороны, вариант забить и отдавать secret key в исходниках тоже может быть допустим. Ведь на самом деле никаких преград для получения secret key нет и поэтому и особого смысла использовать чужие secret key нет (проще наполучать своих, даже в плохих целях). Например, те же мобильные клиенты для ВКонтакте (там API тоже требует secret key) хранят его внутри себя, ибо иначе не получится (при авторизации как веб-сервиса нет доступа ко всем функциям). А поскольку они все на Java, то никаких препятствий к получению secret key нет, ибо всё элементарно декомпилируется.

Поскольку Google любит зонды, то он предполагает, что у юзера к ним уже развита достаточная толерантность

Как сказано-то! Даже и прибавить нечего...

С другой стороны, вариант забить и отдавать secret key в исходниках тоже может быть допустим. Ведь на самом деле никаких преград для получения secret key нет

...Кроме гипотетической, но неприятной вероятности, что гугль может обидеться за применение того, что он явно запретил, и начнёт прибегать к банам и пр.

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

но, главное, эти гады предоставляют библиотеки интерфейсов для своего поделия, но на С или C++ - нишиша. хотя у них на серверах работает именно сишный софт. а для дарагих девелоперов у них выставлена наружу всякая х-ня в виде жаб, пистонов и прочего ненужно. получается, что мне надо дублировать все их интерфейсные шняги в условиях хренового документирования с их стороны. очень сомнительный труд.

да и вообще направление деятельности у них в последние годы - в сторону копирастии и всё большей проприетарщины. поэтому мне как-то не особо и хотелось копать слишком глубоко. я так прикинула: ну вот, допустим, сделаю я такую библиотеку, положу на разгребание плохо документированных протоколов месяц своего личного времени. а они возьмут и поменяют протокол. или закроют API. они так уже делали: раньше было больше возможностей в API. были API к поисковой системе. потом их прикрыли. и могут прикрыть что угодно. и толку от всей возни будет ноль. поэтому лучше чем-нибудь другим заняться, более надёжным и интересным. с копирастами связываться не стоит. сколько было попыток делать замены всяким скайпам и прочим ICQ. это вечная борьба разработчиков и копирастов. я не настолько фанат, чтобы тащить такой груз.

Они должны быть в исходниках программы...
Если программа под GPL. то придётся отдавать.

Да блин! Ну при чем, при чем здесь исходники и договор?

Вы их либо распространяете вместе с программой (будь она свободной или нет, в исходниках или в об’ектниках), либо не распространяете.

Вы их либо распространяете вместе с программой (будь она свободной или нет, в исходниках или в об’ектниках), либо не распространяете.

А разве можно распространять GPL программу вместе с закрытым объектником (на который исходников не предоставлять)?

создаём запрос по формату, приделываем туда хэдер - а-ля «йа мозилко» - и вуаля. главное - получить токен

В этот запрос ещё пользователь должен свой логин/пароль ввести. OAuth как раз и придуман, если пользователь твоей программе не доверяет, а гуглу доверяет.

но, главное, эти гады предоставляют библиотеки интерфейсов для своего поделия, но на С или C++ - нишиша

https://google.github.io/google-api-cpp-client/latest/guide/oauth2.html

В этот запрос ещё пользователь должен свой логин/пароль ввести

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

https://google.github.io/google-api-cpp-client/latest/guide/oauth2.html

у них почему-то нет этой плюсовой библиотеки в списке библиотек API в документации к их API. то есть, где её искать - неочевидно.

впрочем, я посмотрела - для сборки там сначала надо малость повыкусывать питонятину. ибо если на машине нет пистона, то их скрипт с зависимостями в пролёте. но это мелочи.

он должен это сделать, введя свой логин и пароль

В случае OAuth он не вводит их в программу, а вводит их на сайте гугла. Таким образом, программа не может позже зайти от его имени и сделать что-нибудь ещё.

для меня весь смысл ковыряния их API был в том, чтобы избавиться от браузера и использовать сервисы из консоли.

Можно. https://developers.google.com/identity/protocols/OAuth2ServiceAccount

что такое браузер? это просто фигня, которая посылает какие-то запросы в сеть. и формат этих запросов даже где-то в их документации описан. правда, глубоко зарыт и хрен найдёшь с первого раза

Это вы про http?

в чём проблема получить токен на машине где есть браузер а потом передать его на сервер? rclone так работает например

на самом деле, всё не так плохо. что такое браузер? это просто фигня, которая посылает какие-то запросы в сеть. ... создаём запрос по формату, приделываем туда хэдер - а-ля «йа мозилко» - и вуаля. главное - получить токен.

Там не так всё просто. Да, можно прикинуться headless-браузером, но придётся обработать несколько вариантов, которые тебе гугл может вернуть после первого запроса, например:

• в простейшем случае он может просто написать, что всё нормально, вы можете закрыть эту страницу - если это не первый запрос;
• если с этого браузера в гугл ходили под разными аккаунтами, он может предложить выбрать один из них и, возможно, ввести пароль;
• если история пуста, может предложить ввести имя и пароль.

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

Короче, да - если связываться с консольным приложением, то на вход ему уже готовый токен. А я решил пока хотя бы гуёвое осилить.

P.S. Пока писал, подумал, что в принципе-то, через xdg-open браузер можно вызвать и из консольного приложения - разумеется, с ограничением, что это консольное приложение, запущенное под иксами.

вот именно это я и делала. только через протоколы по документации, на сишечке.

какая разница? снять логи и распарсить на своей стороне на любом протоколе.

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

если с этого браузера в гугл ходили под разными аккаунтами

это не наш случай. мы же не будем скармливать ему куки браузера. а без куки это просто вход без каких-либо заранее известных условий.

в случае с запросами всё как раз просто. на сервер уходит запрос (не абы какой) и сервер присылает ответ (тоже вполне определённый). ему не нужен http в полном объёме. http тут только для юзерского интерфейса, чтобы сформировать запрос. а нам нужен только конечный вариант. и его обычно хватает, ибо нам нужен токен. мы можем сразу сформировать ответ, без парсинга и без всяких действий якобы юзера.

Начни с лора.

а лор прекрасно читается в elinks. и комментировать там можно без проблем. в нём ничего не надо добавлять или убирать.