Fix #7854 Adds authorization code grant type flow to Api V8 OAuth2 #8291
Conversation
HVStechnik
force-pushed
the
feature/7854-api-authorization-code-grand
branch
from
ed747b2
to
d317328
Compare
| 'view_print' => false, | ||
| ); | ||
|
|
||
| public function display() |
There was a problem hiding this comment.
Not required but it would be good to reduce the cognitive complexity of this function.
There was a problem hiding this comment.
That is absolutely true. I thought about moving the decision points (show the authorization page or redirect once the decision has been made) to the controller class. However, we need the \Slim\App and \AuthorizationServer instances to validate the request, show the decision form, and to send the response. Since I cannot send the $app and $server instances to the display() function as params (the display function is called outside the module), there is no way to use the same AuthorizationServer instance in the controller and the view classes. I did not want to create those instances twice and thus ended up doing everything in the display function.
There are two options that might work:
- Attach the \Slim\App and \AuthorizationServer instances to an instance of \OAuth2AuthCodes, which is created at the beginning of the display() function. We could then use multiple functions of the \OAuth2AuthCodes class to do the logic.
- Split the display function into several function within the Oauth2AuthCodesViewAuthorize class. That might be easier to read, but still has the logic within the view class, where is should not be...
@Dillon-Brown: Do you have a preferred option? Or shall I leave the complex display function as it is for now?
|
Also looks like Travis is failing the acceptance tests:
|
HVStechnik
force-pushed
the
feature/7854-api-authorization-code-grand
branch
from
a9607ba
to
52704b4
Compare
…APP. labels in list view custom code
HVStechnik
dismissed stale reviews from Dillon-Brown and code-ph0y
via
291d5db
Codecov Report
@@ Coverage Diff @@
## hotfix-7.10.x #8291 +/- ##
=================================================
+ Coverage 10.57% 10.58% +0.01%
=================================================
Files 3226 3240 +14
Lines 239933 240356 +423
=================================================
+ Hits 25361 25444 +83
- Misses 214572 214912 +340 |
|
I just fould and solved the issue that caused Travis to fail. |
|
Issues
======
- Added 6
See the complete overview on Codacy |
|
Hi SalesAgility team, |
Codecov Report
@@ Coverage Diff @@
## hotfix-7.10.x #8291 +/- ##
=================================================
- Coverage 10.70% 10.69% -0.01%
=================================================
Files 3230 3243 +13
Lines 241058 241384 +326
=================================================
+ Hits 25798 25811 +13
- Misses 215260 215573 +313 |
|
I've resolved conflics that emerged due to recent updates on the hotfix branch. |
|
|
mattlorimer
force-pushed
the
hotfix-7.10.x
branch
2 times, most recently
from
3149dea
to
ab954a4
Compare
mattlorimer
force-pushed
the
hotfix-7.10.x
branch
from
1609e8b
to
b06335d
Compare
As discussed in #7854 this adds the OAuth2 authorization code grant type flow to the Api V8. The code leverages thephpleague's OAuth2 Server and follows the implementation guidelines.
The PR covers the following main changes:
OAuth2AuthCodesThe OAuth2 authorization code flow includes the following steps:
a. decline the request, which redirects the user back to the client (the redirect contains an approapriate hint)
b. authorize the client, which creates a new authorization code. The code is saved as a new record in the OAuth2AuthCode module. The user is redirected to the client. The redirect url contains the authorization code.
Api/access_tokenaccess point. The OAuth2 Server then again validates the client and additionally the client secret and the authorization code. If both are valid and match a new access_token on behalf of the authorizing user is returned. This access_token now grants the client access to the V8 Api. The client thereby acts as the authorizing user.Motivation and Context
Access to the V8 Api is currently granted by either a client credentials grant or a password grant. The client credentials grant has the downside, that it allows to access the Api on behalf of a dedicated user only (the user is defined in the admin area). The password grant has the downside that the client system needs to handle the user's SuiteCRM password to obtain access to the Api, which is a potential security risk. The authoriazion code grant solves these issues.
Additional feature and implementation description
In line with similar implementations in other systems, we offer the user a third option (besides authorizing and declining the request): The user can choose to save the authorization decision for future requests. We thenflag the OAuth2AuthCode record. The flag first prevents that the record is deleted once the authorization code is expired (the code though does expire). Second, if a new authorization code is requested by that particular client AND if the corresponding user is logged-in into SuiteCRM a new authorization code is returned without showing the decision page. The authorize view looks as follows (my color scheme is blue...):
The OAuth2AuthCodes module appears in the module list, because users can access the list view. For normal users, the list view lists the authorization codes for that particular user. For admins, the list view lists all authorization codes. The list view is accessible for normal users, because they can revoke their authorization codes there. This is in particular relevant for the authoriation codes that have been saved for automatic approval of future requests (see point 4).
If a client redirects a user to the SuiteCRM instance (to obtain an auth code) and if that user is not logged-in already, the user will be redirected to the login page (the user logs-in in order to obtain the authorization code for the client). In this case, the user is logged-out automatically once the authorization request has been approved or declined. This is because we do not want to keep a logged-in SuiteCRM session, the user might not be aware of, because once the user is redirected to the client, there is no open SuiteCRM window any more.
How To Test This
path-to-instance/Api/authorize?response_type=code&client_id=[client identifier]&redirect_uri=[redirect_url]Please ask, if there are any questions! I'm happy to furhter explain and improve the code in case of any recommendations.
Types of changes
Final checklist