Under what circumstances will the refresh token be invalidated?
I don't know, but isn't that up to the resource owner? As in, why would
nmh care?
Well, I was just more curious myself as to how it all worked in practice,
just for my own curiousity.
All parameters configuring the service may be overridden by profile
components, and even though only Gmail is supported out of the box, the
user can define new services entirely in the profile. Profile
components are prefixed by oauth-service-, for example, oauth-gmail-
credential-file which specifies where mhlogin should write credentials
and where send should read them.
And post doesn't read the profile. This also allows a postproc to do
things that send/post can't.
Oh, hm. Drat, there is that.
It occurs to me that this makes it hard to have a postproc that sends
to different mail servers based on the "From" address ... because this
mechanism is unique in that it requires "send" to generate the access
token, and you can't change things when postproc is called.
And ... wait a second. SASL mechanisms read the "credentials" entry
in your .mh_profile, and that works inside of post(8).
Ah, I see. THAT works because send(1) reads the profile for you and
passes down the "credentials" entry via the -credentials switch.
Hm. Could something like that work for post? It would require some
rejiggering (that I would be willing to do), but instead of passing down
the access token on the post command line, we could do:
-oauth-cred-file <cred file>
-oauth-client-id client_id
-oauth-client-secret client_secret
... and so on.
A postproc could get all of those entries via mhparam. That seems like it
"fits" a bit better. Thoughts? Like I said, I'd be willing to do this
work since I'm the one asking for it.
Related to this ... it has finally reached my level of annoyance that
inc cannot do TLS for POP. I think that should be fixed for 1.7, and
I'm proposing I do that work as well. I'm assuming nobody objects
to that.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers