I think packages such as this one are very welcome, and I appreciate the
UI-agnostic architecture you describe.

Url.el itself, last i looked, seemed a bit outdated and hard to work with.
Are there other http client libraries for Emacs? Could they also take
advantage of your new library?

João

On Sat, May 6, 2023, 06:07 Thomas Fitzsimmons <fitzsim@fitzsim.org> wrote:

> Hi,
>
> I would like to add one or two new packages to GNU ELPA.
>
> The main one is url-http-oauth, which adds OAuth 2.0 support to the URL
> library, via "url-auth" hooks, like url-http-basic, url-http-digest and
> url-http-ntlm.  It provides auth-source integration for secrets, using
> the netrc backend.
>
>    https://git.sr.ht/~fitzsim/url-http-oauth
>
> This package is unrelated to oauth2.el in GNU ELPA, which provides new
> oauth2-url-retrieve and oauth2-url-retrieve-synchronously functions, and
> has plstore instead of auth-source integration.  For Excorporate, I
> needed something that would work with the built-in url-retrieve
> functions and I couldn't see how to do that with oauth2.el.  I haven't
> tested, but I see no reason that the two packages would interfere with
> one another.
>
> For the next release of Excorporate I want to depend on url-http-oauth
> to fix the longstanding bug#50113, "Excorporate: Communicating with
> domain that requires SSO?".  I have the changes ready; I am using them
> daily.
>
> The OAuth 2.0 standard encodes the use of a user-agent (i.e., web
> browser) for authorization steps which differ per OAuth 2.0 provider,
> and are not defined by the specification.  I have provided support for
> package authors and users to write custom functions to automate these
> web browser interactions in arbitrary ways:
>
>    AUTHORIZATION-CODE-FUNCTION is an elisp function that takes an
>    authorization URL as a string argument, and returns, as a string, a
>    full URL containing a code value in its query string.
>
> By default though, url-http-oauth will prompt the user to copy-n-paste
> URLs to and from the web browser.  This is the most general default I
> could think of; for example, this allows performing authorization in a
> local web browser then pasting the result to an Emacs session running
> three SSH hops away, where `browse-url' may not do the right thing.
>
> Users and package authors can design automatic user-agent interactions,
> but those ways are so varied that I wanted to see how they would evolve.
> For example, I would like to see someone write an
> authorization-code-function for Sourcehut that would use EWW inline.
> For other OAuth 2.0 providers whose authorization steps require
> JavaScript, EWW would not work.
>
> I have published another, tiny package:
>
>    https://git.sr.ht/~fitzsim/url-http-oauth-demo
>
> It demonstrates the use of url-http-oauth against the Emacs-friendliest
> OAuth 2.0 implementation I've found: Sourcehut.  Sourcehut's
> implementation is entirely Free Software, and it does not require
> JavaScript in the authorization steps.  Its client registration process
> does not have onerous terms of use.  Any Sourcehut user should be able
> to get url-http-oauth-demo working.  Maybe this package makes sense in
> GNU ELPA, or perhaps it could be part of url-http-oauth's documentation.
>
> I wrote these packages myself [1] and I have copyright assignment
> paperwork on file.
>
> Thomas
>
> 1. Except url-http-oauth--netrc-delete, which borrows lots of code from
>    auth-source.el.
>
>