GNU bug report logs -
#16880
24.3; oauth2: 401-responses not handled transparently [oauth2 0.10]
Previous Next
Reported by: Øyvind Stegard <oyvinst <at> ifi.uio.no>
Date: Tue, 25 Feb 2014 14:11:02 UTC
Severity: normal
Tags: moreinfo
Found in version 0.10
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16880 in the body.
You can then email your comments to 16880 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
help-debbugs <at> gnu.org
:
bug#16880
; Package
oauth2
.
(Tue, 25 Feb 2014 14:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Øyvind Stegard <oyvinst <at> ifi.uio.no>
:
New bug report received and forwarded. Copy sent to
help-debbugs <at> gnu.org
.
(Tue, 25 Feb 2014 14:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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,
Øyvind S.
--
< Øyvind Stegard
< http://stegard.net/
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16880
; Package
emacs
.
(Tue, 25 Feb 2014 16:52:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 16880 <at> debbugs.gnu.org (full text, mbox):
Ø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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16880
; Package
emacs
.
(Sat, 29 May 2021 11:53:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16880 <at> debbugs.gnu.org (full text, mbox):
Øyvind Stegard <oyvinst <at> ifi.uio.no> writes:
> 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.
(I'm going through old bug reports that unfortunately got no response at
the time.)
Are you still seeing this issue with more recent versions of oauth2?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 29 May 2021 11:53:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16880
; Package
emacs
.
(Sat, 26 Jun 2021 12:44:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 16880 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Are you still seeing this issue with more recent versions of oauth2?
More information was requested, but no response was given within a
month, so I'm closing this bug report. If the problem still exists,
please respond to this email and we'll reopen the bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
16880 <at> debbugs.gnu.org and Øyvind Stegard <oyvinst <at> ifi.uio.no>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 26 Jun 2021 12:44:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 25 Jul 2021 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.