GNU logs - #16880, boring messages


Message sent to help-debbugs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#16880: 24.3; oauth2: 401-responses not handled transparently [oauth2 0.10]
Resent-From: =?UTF-8?Q?=C3=98yvind?= Stegard <oyvinst@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: help-debbugs@HIDDEN
Resent-Date: Tue, 25 Feb 2014 14:11:02 +0000
Resent-Message-ID: <handler.16880.B.139333745824804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 16880
X-GNU-PR-Package: oauth2
X-GNU-PR-Keywords: 
To: 16880 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.139333745824804
          (code B ref -1); Tue, 25 Feb 2014 14:11:02 +0000
Received: (at submit) by debbugs.gnu.org; 25 Feb 2014 14:10:58 +0000
Received: from localhost ([127.0.0.1]:38800 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WIIio-0006Rz-0c
	for submit <at> debbugs.gnu.org; Tue, 25 Feb 2014 09:10:58 -0500
Received: from eggs.gnu.org ([208.118.235.92]:56476)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIil-0006Rk-GF
 for submit <at> debbugs.gnu.org; Tue, 25 Feb 2014 09:10:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiZ-0007T3-3y
 for submit <at> debbugs.gnu.org; Tue, 25 Feb 2014 09:10:50 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled
 version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:56664)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiZ-0007Sz-0t
 for submit <at> debbugs.gnu.org; Tue, 25 Feb 2014 09:10:43 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58125)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiS-0008RN-Az
 for bug-gnu-emacs@HIDDEN; Tue, 25 Feb 2014 09:10:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiK-0007O4-El
 for bug-gnu-emacs@HIDDEN; Tue, 25 Feb 2014 09:10:36 -0500
Received: from mail-out2.uio.no ([129.240.10.58]:51703)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiK-0007N5-42
 for bug-gnu-emacs@HIDDEN; Tue, 25 Feb 2014 09:10:28 -0500
Received: from mail-mx2.uio.no ([129.240.10.30])
 by mail-out2.uio.no with esmtp (Exim 4.75)
 (envelope-from <oyvind.stegard@HIDDEN>) id 1WIIiH-0007aR-8Q
 for bug-gnu-emacs@HIDDEN; Tue, 25 Feb 2014 15:10:25 +0100
Received: from 1x-193-157-241-193.uio.no ([193.157.241.193]
 helo=rednorrock.local)
 by mail-mx2.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128)
 user oyvinst (Exim 4.80) (envelope-from <oyvind.stegard@HIDDEN>)
 id 1WIIiG-0001D1-Nc
 for bug-gnu-emacs@HIDDEN; Tue, 25 Feb 2014 15:10:25 +0100
From: =?UTF-8?Q?=C3=98yvind?= Stegard <oyvinst@HIDDEN>
Date: Tue, 25 Feb 2014 15:10:23 +0100
Message-ID: <87fvn7jnao.fsf.rednorrock@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 1 sum msgs/h 1 total
 rcpts 58 max rcpts/h 3 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0,
 autolearn=disabled, RP_MATCHES_RCVD=-1.511, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO,
 uiouri=NO)
X-UiO-Scanned: A962A86F2539BE3205581682E7D8920C13DC4D82
X-UiO-SPAM-Test: remote_host: 193.157.241.193 spam_score: -64 maxlevel 80
 minaction 2 bait 0 mail/h: 1 total 46 max/h 3 blacklist 0 greylist 0
 ratelimit 0
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Package: oauth2
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.
--=20
< =C3=98yvind Stegard
 < http://stegard.net/




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: =?UTF-8?Q?=C3=98yvind?= Stegard <oyvinst@HIDDEN>
Subject: bug#16880: Acknowledgement (24.3; oauth2: 401-responses not
 handled transparently [oauth2 0.10])
Message-ID: <handler.16880.B.139333745824804.ack <at> debbugs.gnu.org>
References: <87fvn7jnao.fsf.rednorrock@HIDDEN>
X-Gnu-PR-Message: ack 16880
X-Gnu-PR-Package: oauth2
Reply-To: 16880 <at> debbugs.gnu.org
Date: Tue, 25 Feb 2014 14:11:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 help-debbugs@HIDDEN

If you wish to submit further information on this problem, please
send it to 16880 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
16880: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D16880
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#16880: 24.3; oauth2: 401-responses not handled transparently [oauth2 0.10]
Resent-From: Glenn Morris <rgm@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Feb 2014 16:52:01 +0000
Resent-Message-ID: <handler.16880.B16880.13933470799986 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 16880
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?=C3=98yvind?= Stegard <oyvinst@HIDDEN>
Cc: 16880 <at> debbugs.gnu.org
Received: via spool by 16880-submit <at> debbugs.gnu.org id=B16880.13933470799986
          (code B ref 16880); Tue, 25 Feb 2014 16:52:01 +0000
Received: (at 16880) by debbugs.gnu.org; 25 Feb 2014 16:51:19 +0000
Received: from localhost ([127.0.0.1]:39633 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WILDy-0002az-EL
	for submit <at> debbugs.gnu.org; Tue, 25 Feb 2014 11:51:18 -0500
Received: from fencepost.gnu.org ([208.118.235.10]:49808 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rgm@HIDDEN>) id 1WILDw-0002ar-LM
 for 16880 <at> debbugs.gnu.org; Tue, 25 Feb 2014 11:51:17 -0500
Received: from rgm by fencepost.gnu.org with local (Exim 4.71)
 (envelope-from <rgm@HIDDEN>)
 id 1WILDu-0007Nh-Uq; Tue, 25 Feb 2014 11:51:15 -0500
From: Glenn Morris <rgm@HIDDEN>
References: <87fvn7jnao.fsf.rednorrock@HIDDEN>
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
Date: Tue, 25 Feb 2014 11:51:14 -0500
In-Reply-To: <87fvn7jnao.fsf.rednorrock@HIDDEN> ("=?UTF-8?Q?=C3=98yvind?= Stegard"'s
 message of "Tue, 25 Feb 2014 15:10:23 +0100")
Message-ID: <bflhwz3zlp.fsf@HIDDEN>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

=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.





Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.