[Home]

Summary:ASTERISK-27207: XMPP OAuth not working due to inverted logic
Reporter:Michael Kuron (mkuron)Labels:
Date Opened:2017-08-20 07:08:39Date Closed:2017-08-22 07:45:38
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_xmpp
Versions:13.18.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian Jessie amd64Attachments:
Description:ASTERISK-27169 introduced OAuth support into res_xmpp. The change was cherry-picked into Asterisk 13 as commit 54e3ac402ff167ba2463b386ea25fa5327be86c6. Unfortunately, it seems like the cherry-picked code does not actually work , likely due to func_curl changes in Asterisk 14 and higher (probably commit 6bbcfb34bd411ec88a02e6c655b0d5b9821495a4). The token is correctly refreshed via func_curl, but the resulting XML is never copied to the read buffer. The error message displayed claims that "CURL is unavailable.", which is inaccurate -- CURL is available, only the XML is never passed back. The relevant log lines are shown below. I am currently trying to work up a patch to fix this in Asterisk 13.

{code}
DEBUG[22076]: res_xmpp.c:3826 xmpp_client_thread: [google] Connecting
DEBUG[22076]: res_xmpp.c:3658 xmpp_client_reconnect: Obtaining OAuth access token for client 'google'
DEBUG[22076]: res_xmpp.c:3918 fetch_access_token: Performing OAuth 2.0 authentication for client 'google' using command: CURL(https://www.googleapis.com/oauth2/v3/token,client_id=XXX&client_secret=YYY&refresh_token=ZZZ&grant_type=refresh_token)
DEBUG[22076]: func_curl.c:534 WriteMemoryCallback: Called with data=0xb4e2da14, str=0xb6803a50, realsize=199, len=16, used=0
DEBUG[22076]: func_curl.c:538 WriteMemoryCallback: Now, len=256, used=199
DEBUG[22076]: func_curl.c:704 acf_curl_helper: str='{
"access_token": "AAA",
"token_type": "Bearer",
"expires_in": 3600
}'
ERROR[22076]: res_xmpp.c:3921 fetch_access_token: CURL is unavailable. This is required for OAuth 2.0 authentication of XMPP client 'google'. Please ensure it is loaded.
{code}
Comments:By: Asterisk Team (asteriskteam) 2017-08-20 07:08:41.076-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Michael Kuron (mkuron) 2017-08-20 08:08:42.989-0500

Looks like in {{fetch_access_token}}, the logic for checking {{ast_func_read}} is inverted; if I change that, the issue goes away. That function returns 0 upon success, so an error should be returned if the return value is true.
By: Friendly Automation (friendly-automation) 2017-08-22 07:45:39.039-0500

Change 6249 merged by Jenkins2:
res_xmpp: fix inverted return code check in OAuth

[https://gerrit.asterisk.org/6249|https://gerrit.asterisk.org/6249]
By: Friendly Automation (friendly-automation) 2017-08-22 07:52:39.996-0500

Change 6252 merged by Jenkins2:
res_xmpp: fix inverted return code check in OAuth

[https://gerrit.asterisk.org/6252|https://gerrit.asterisk.org/6252]
By: Friendly Automation (friendly-automation) 2017-08-22 07:59:02.445-0500

Change 6253 merged by Joshua Colp:
res_xmpp: fix inverted return code check in OAuth

[https://gerrit.asterisk.org/6253|https://gerrit.asterisk.org/6253]
By: Friendly Automation (friendly-automation) 2017-08-22 07:59:40.523-0500

Change 6254 merged by Jenkins2:
res_xmpp: fix inverted return code check in OAuth

[https://gerrit.asterisk.org/6254|https://gerrit.asterisk.org/6254]