From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.bugs Subject: bug#16880: 24.3; oauth2: 401-responses not handled transparently [oauth2 0.10] Date: Tue, 25 Feb 2014 11:51:14 -0500 Message-ID: References: <87fvn7jnao.fsf.rednorrock@ifi.uio.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1393347121 16423 80.91.229.3 (25 Feb 2014 16:52:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 16:52:01 +0000 (UTC) Cc: 16880@debbugs.gnu.org To: =?UTF-8?Q?=C3=98yvind?= Stegard Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 25 17:52:09 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WILEl-0007Hc-LV for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 17:52:07 +0100 Original-Received: from localhost ([::1]:35838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILEl-0001RS-A8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Feb 2014 11:52:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILEg-0001Jr-Uo for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2014 11:52:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WILEg-0001HQ-2x for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2014 11:52:02 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WILEg-0001HL-0k for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2014 11:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WILEf-0002cD-Jp for bug-gnu-emacs@gnu.org; Tue, 25 Feb 2014 11:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Glenn Morris Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Feb 2014 16:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16880 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16880-submit@debbugs.gnu.org id=B16880.13933470799986 (code B ref 16880); Tue, 25 Feb 2014 16:52:01 +0000 Original-Received: (at 16880) by debbugs.gnu.org; 25 Feb 2014 16:51:19 +0000 Original-Received: from localhost ([127.0.0.1]:39633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WILDy-0002az-EL for submit@debbugs.gnu.org; Tue, 25 Feb 2014 11:51:18 -0500 Original-Received: from fencepost.gnu.org ([208.118.235.10]:49808 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WILDw-0002ar-LM for 16880@debbugs.gnu.org; Tue, 25 Feb 2014 11:51:17 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WILDu-0007Nh-Uq; Tue, 25 Feb 2014 11:51:15 -0500 X-Spook: NASA MD2 Firewalls LABLINK Al Jazeera anarchy advisors X-Ran: .|wzFVA=/2M0#/Z?E"Ip=^}mvhP\TM4v*usD/o}:]:{ac_{POZ.U"J%ugp)5ccJfZ=?%9A X-Hue: red X-Attribution: GM In-Reply-To: <87fvn7jnao.fsf.rednorrock@ifi.uio.no> ("=?UTF-8?Q?=C3=98yvind?= Stegard"'s message of "Tue, 25 Feb 2014 15:10:23 +0100") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86188 Archived-At: =C3=98yvind 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, > > =C3=98yvind S.