Ken Hornstein <[email protected]> writes: > >Yes. Refresh tokens, unlike access tokens, are long-lived. > >However, either may stop working at any time, for any unspecified > >reasons. > > Thanks for the info! > > One thing that jogs my memory; you said before you had created a nmh > project to register the client key and secret for nmh, and that we should > resolve the ownership of that. I think we should get other developers > involved on that project, just in case something happens to you.
David Levine is a co-owner of the Google developer project. Either of us can add other owners. Apparently, you have to use a Gmail account, not just any Google account. > Also, I do have a question about that ... obviously our client "secret" > isn't really secret, since it's embedded in our source code which is > available for download. Is that to identify apps so users have more Yep: https://tools.ietf.org/html/rfc6749#section-2.1 > fine-grained permission control? Do other open-source applications > just embed the secret in their source code? I guess that means other > applications could take our secret and pretend to be nmh; I'm not sure > that's a problem, but I just wanted to understand it. Nothing can stop anyone else from using the client-id. It serves no security purpose in this scenario. Thanks. _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
