ship oauth2 client_id and client_secret

[gauteh]

this way a user does not need to get his own API key, though it might be
safer. as far as I can see, there should be no way to access mail
without getting the access and refresh tokens with the users consent.

according to: https://developers.google.com/identity/protocols/OAuth2#installed client_id and client_secret is not so-secret in these types of applications, but who know how this works..

a malicious attacker might steal the id and secret and use it in his own
project, this might use the app quota, but should not be able to access
user account.

some more discussion:

• http://stackoverflow.com/questions/25957027/oauth-2-installed-application-client-secret-considerationsgoogle-api/43061998#43061998
• http://stackoverflow.com/questions/19615372/client-secret-in-oauth-2-0?rq=1

[gauteh]

Hope for some comment here: http://stackoverflow.com/questions/43173367/is-it-safe-to-distribute-client-id-and-client-secret-for-google-api-for-an-insta

[gauteh]

odeke-em/drive#44

[odeke-em]

@gauteh in regards to #9 (comment)

a malicious attacker might steal the id and secret and use it in his own
project, this might use the app quota, but should not be able to access
user account.

that's pretty much like another user using your app ;) We use the shipped client_secret and client_id too in drive, and for the past 3+ years, there haven't been problems except with quota exhaustions from a Google Drive platform bug.

[gauteh]

@odeke-em: thanks for the clarifications! This should confirm that we can ship the id and secret, and the user must keep the access-token and refresh-token safe.

[make-github-pseudonymous-again]

Does that mean each client gets its own API key or do we still have to generate our own to avoid hitting api limits as suggested in the README?

[gauteh]

Aurélien Ooms writes on June 19, 2018 18:53:

Does that mean each client gets its own API key or do we still have to generate our own to avoid hitting api limits as suggested in the README?

All users share the default key. You can try to use your own key to avoid API limits. However, it is more likely that you might be hitting your account limits. Check the wiki for some more details: https://github.com/gauteh/gmailieer/wiki#initial-synchronization-time Are you on the initial sync? And have you made any full/massive account downloads lately? Either through gmailieer, IMAP, or by other means?

[make-github-pseudonymous-again]

Do you mean that the default key has highers limits? I am currently going through an initial sync. I generated my own key, downloaded it, and ran gmi auth -c client_id.json. Is that how I was supposed to use it? I was just unsure of the meaning of this pull request. I thought it meant you were generating a personal key as part of the initialization.

[gauteh]

No, it is not special. Before this PR we did not ship a key and all users had to generate their own. tir. 19. jun. 2018 kl. 20:14 skrev Aurélien Ooms <notifications@github.com>:

…

Do you mean that the default key has highers limits? I am currently going through an initial sync. I generated my own key, downloaded it, and ran gmi auth -c client_id.json. Is that how I was supposed to use it? I was just unsure of the meaning of this pull request. I thought it meant you were generating a personal key as part of the initialization. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADd-weWwdMr-ZUbJFtQrzYKSA0dRXcdks5t-T-igaJpZM4MxpRH> .

[gauteh]

Yes, that is how you generate it. But you might have to re-auth if you first used the default one. See cmd line args for auth. tir. 19. jun. 2018 kl. 20:53 skrev Gaute Hope <eg@gaute.vetsj.com>:

…

No, it is not special. Before this PR we did not ship a key and all users had to generate their own. tir. 19. jun. 2018 kl. 20:14 skrev Aurélien Ooms ***@***.*** >: > Do you mean that the default key has highers limits? I am currently going > through an initial sync. I generated my own key, downloaded it, and ran gmi > auth -c client_id.json. Is that how I was supposed to use it? I was just > unsure of the meaning of this pull request. I thought it meant you were > generating a personal key as part of the initialization. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#9 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AADd-weWwdMr-ZUbJFtQrzYKSA0dRXcdks5t-T-igaJpZM4MxpRH> > . >

[gauteh]

Err... not generate — use. tir. 19. jun. 2018 kl. 20:54 skrev Gaute Hope <eg@gaute.vetsj.com>:

…

Yes, that is how you generate it. But you might have to re-auth if you first used the default one. See cmd line args for auth. tir. 19. jun. 2018 kl. 20:53 skrev Gaute Hope ***@***.***>: > No, it is not special. Before this PR we did not ship a key and all > users had to generate their own. > > tir. 19. jun. 2018 kl. 20:14 skrev Aurélien Ooms < > ***@***.***>: > >> Do you mean that the default key has highers limits? I am currently >> going through an initial sync. I generated my own key, downloaded it, and >> ran gmi auth -c client_id.json. Is that how I was supposed to use it? I >> was just unsure of the meaning of this pull request. I thought it meant you >> were generating a personal key as part of the initialization. >> >> — >> You are receiving this because you modified the open/close state. >> Reply to this email directly, view it on GitHub >> <#9 (comment)>, or mute >> the thread >> <https://github.com/notifications/unsubscribe-auth/AADd-weWwdMr-ZUbJFtQrzYKSA0dRXcdks5t-T-igaJpZM4MxpRH> >> . >> >