This repository was archived by the owner on Jan 17, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 17, 2023. It is now read-only.
It's not possible to retrieve secondary data from the authentication request #84
Description
It's not uncommon to include additional data in a successful OAuth response. How come only the token is accessible in the success handler?
I realize this won't be easy to change for backwards compatibility reasons, but if a major version is coming up, it would be nice to have the block signatures (mostly) match all the standard AFNetworking ones by simply adding the AFHTTPRequestOperation *operation parameter in front. While the second argument to success would still be AFOAuthCredential, the developer can choose to extract extra parameters from the AFHTTPRequestOperation instance's responseObject property.
In the meantime, perhaps something could be done to support accessing the additional parameters?
Activity
blixt commentedon Dec 23, 2014
For some examples of OAuth endpoints that return extra data you can find some here:
machine_idfield)app_idfield)itsthejb commentedon Jan 28, 2015
Indeed, same issue here - most OAuth APIs I've worked with return the authenticated user in the auth request success response.
OmarPedraza commentedon Apr 22, 2015
+1
The OAuth2 server I'm working with returns a bad request status when user or password are invalid and includes a description error in the responseObject, so I need to access to the responseObject to give the user more information about the error.
Added the data task and response object as a callback argument for the
jroa919 commentedon Jan 27, 2016
+1
Our OAuth2 server also returns HTTP/1.1 400 Bad request for an invalid username/password combination. AFNetworking returns this as an error and this is obscured when the failure(...) block omits the data task argument.
On the topic of extendability, we are using an OpenID Connect server that returns additional information in the authentication request responseObject (such as 'id_token', etc.). This information is also lost in the success(...) block.
Looking at #112, those changes achieve exactly what I'm looking for. Hoping to see this merged into the 3_0_0_branch.
boojapathyc commentedon Aug 7, 2016
any updates on this issue.