AuthX - Extended authentication support (portable and router-friendly) #19590
Conversation
|
(Standard links)
|
2f0a236 to
b2692be
Compare
ba87ea5 to
e693885
Compare
|
I've had some success using this for authenticated email links in Afform (#19660). Removing the "(WIP)" flag. There are some ideas in the description that haven't been done (e.g. a configuration UI and strict APIv3 REST interop). However, I don't think these are actually needed for the immediate goal of Afform/token support. They would matter more for achieving another goals (e.g. D8 REST), but I'm happy to kick that down to another issue/PR. |
|
Based on the last discussion, I've fully extracted the Joomla bugfixes as a set of parallel PRs so that they can be reviewed on a separate timeline. In no particular order, they are:
Additionally, the GuzzleMiddleware bit is available as a separate PR #19678. |
|
@totten can you rebase this please given that the core PRs have been mostly been merged |
…as a Civi contact
…-vs-string for user/contact ID
This significantly trims down the `auth()` method and rearranges as three
methods. A data object is passed between the three methods. The main method:
```
if ($principal = $this->checkCredential($tgt)) {
$tgt->setPrincipal($principal);
}
$this->checkPolicy($tgt);
$this->login($tgt);
```
This arrangement lays the groundwork for implementing more varied policies.
For example, we could have a policy where the ability to login via
username/password/api_key is dictated by the user's role or permissions.
|
@seamuslee001 Sure. Rebased. |
| <releaseDate>2021-02-11</releaseDate> | ||
| <version>1.0</version> | ||
| <develStage>alpha</develStage> | ||
| <compatibility> |
There was a problem hiding this comment.
@totten should we be hiding this extension from the GUI at this point or not?
There was a problem hiding this comment.
@seamuslee001 My vote would be to show it, but I don't feel super strongly in the first release with it.
There was a problem hiding this comment.
Yeh I guess the question I have is how supported is this but in any case I think its probably ok to show it
|
I note that 95% of this PR is all the extension and the only changes to core code are very minimal and are only about a new hook / event and creating a fake session which is only called from within the extension so I think this is all very safe to be added merging |
Overview
This pull request introduces an extension,
authx, which broadly improves support for HTTP authentication on any CiviCRM route. For example:Some key features:
Basic {user:pass})api_key(Bearer {token})Bearer {token})?_authx=<CRED>)Authorization:<CRED>)X-Civi-Auth:<CRED>)/civicrm/authx/login,/civicrm/authx/logout)?_authx=<CRED>&authxSes=1)Civi\Authx\AllFlowsTestis an E2E test which covers every permutation of credentials+flows on every CMS.The extension should help with several problems:
civicrm/my-form?_authx=MY_JWT)authx, then the existing AJAX route (civicrm/ajax/api4/ENTITY/ACTION) should be usable for REST purposes.authx, then the existing AJAX route (civicrm/ajax/rest) should be usable for REST purposes. (dev/core#2077)Before
A handful of end-points (
extern/rest.php,extern/cron.php) are able to accept requests based on anapi_key. However, the code which implements this is extremely convoluted. Consequently, it is difficult to fix or improve.After
Any CiviCRM route can accept an authentication token.
Comments
Why do this as a core extension?
Technical Details
There's more information about the intended list of features in
ext/authx/README.md.These bits would be good additions, but I think it's mergable without them:
extern/rest.phptocivicrm/ajax/restwithout changing logic.civicrm/ajax/rest, then accept?api_key=XXXas an alias for?_authx=Bearer+XXX.site_keyenforcement: Some admins may currently rely onsite_keyto distinguish between users who are or are not allowed to use REST-y dataflows. For JWT, the extra grant is implicit. However, forapi_keyandpasswordbased auth it may be appropriate to have an option forsite_keyenforcement.I've been able to successfully run
AllFlowsTestlocally on every CMS. However, there were a few quirks/caveats. I don't think they're blockers for this PR.drush cc router: When you first enable the extension, D8's routing table remains stale. Clear it.sendsExcessCookies: It sometimes sends aSet-Cookie:in responses which don't merit a cookie.Authorization:: To support commonAuthorization:headers, one must add a line to.htaccess. But if you're happy with the other flows, then don't worry about it. Other flows work out-of-the-box.sendsExcessCookies: It sometimes sends aSet-Cookie:in responses which don't merit a cookie.authErrorShowsForm: In some error cases, it does not report the error well@user:<name>. #19615, Joomla - Allow E2E unit-test. Use Joomla Session API (and fake it when neceesary) #19616, CiviCRM-Joomla should accept web-service calls civicrm-joomla#58civicrm-joomla.gitin a subdir.civihydra create /path/to/civicrm-XYZ-joomla.zip