unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Glenn Morris <rgm@gnu.org>
To: "Øyvind Stegard" <oyvinst@ifi.uio.no>
Cc: 16880@debbugs.gnu.org
Subject: bug#16880: 24.3; oauth2: 401-responses not handled transparently [oauth2 0.10]
Date: Tue, 25 Feb 2014 11:51:14 -0500	[thread overview]
Message-ID: <bflhwz3zlp.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87fvn7jnao.fsf.rednorrock@ifi.uio.no> ("Øyvind Stegard"'s message of "Tue, 25 Feb 2014 15:10:23 +0100")

Øyvind Stegard wrote:

> Package: oauth2

There is no package "oauth2" on debbugs.gnu.org, so your report ended up
on the help-debbugs mailing list. You seem to be talking about a GNU
ELPA package, so I have reassigned your issue to the "emacs" package.
This message, and all future ones, will go to the bug-gnu-emacs list.

> Version: 0.10
>
> I use oauth2.el to access the Google Contacts API and it has been
> working fine for a long time. But in recent versions (after v0.9 I
> think) I have been getting 401 http responses from Google whenever a
> token refresh was necessary. Subsequently retrying the http request by
> calling `oauth2-url-retrieve-synchronously' again makes it work OK, and
> "200 OK" with expected results is returned.
>
> It looks like the initial 401 http response, which is supposed to be
> handled transparently, is what actually ends up in the buffer returned
> by `oauth2-url-retrieve-synchronously' when a token refresh has been
> automatically executed (in "oauth-hack" advice around
> `url-http-handle-authentication'). (The token refresh itself seems to
> work fine and is updated in the plstore.)
>
> There is a hack in oauth2.el for hooking into url-http library
> authentication handling, and the hack overrides the standard mechanism
> by using an around-advice ("oauth-hack") and a conditional variable
> which triggers the special behaviour when called from oauth2.
>
> This advice sets the url internal variable `success' to t at the end,
> but the advised function `url-http-handle-authentication' does not do
> this after its own call to `url-retrieve-internal' at the end (in Emacs
> 24.3 at least).
>
> I tried commenting out this (oauth2.el line 205):
>    (when (boundp 'success) (setq success t)) ;For URL library in Emacs<24.4.
>
> so `success' was not set to t. And this causes things to work like
> expected; the initial 401-response is handled behind the scenes, and the
> reponse of the last http request (with updated access token) is what
> ends up in the buffer returned by `oauth2-url-retrieve-synchronously'. I
> have not deep enough knowledge of the url library to see exactly why
> this works, and I would appreciate if you could look into it.
>
> To reproduce, I simply invalidate the access token in the oauth plstore,
> forcing oauth2 to refresh it, before calling function
> `oauth2-url-retrieve-synchronously'.
>
>
> Also, what is the point of the (let ...) block with only variable
> bindings and no body at line 196 in oauth.el ? (Parentheses mishap ?)
>
>
> Thanks,
>
> Øyvind S.





       reply	other threads:[~2014-02-25 16:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87fvn7jnao.fsf.rednorrock@ifi.uio.no>
2014-02-25 16:51 ` Glenn Morris [this message]
2021-05-29 11:52 ` bug#16880: 24.3; oauth2: 401-responses not handled transparently [oauth2 0.10] Lars Ingebrigtsen
2021-06-26 12:43   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bflhwz3zlp.fsf@fencepost.gnu.org \
    --to=rgm@gnu.org \
    --cc=16880@debbugs.gnu.org \
    --cc=oyvinst@ifi.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).