Overview
--------
This slightly relaxes the default settings so that it is easier to use `authx` as a replacement for `extern/rest.php` (which
uses the `api_key` for authentication).
Before
------
`extern/rest.php` accepts `api_key`s.
`authx` can accept `api_key`s, but you have to change some settings to allow it.
After
-----
Both `extern/rest.php` and `authx` accept `api_key`s by default.
Comments
-----------------
The defaults in authx were designed to be a bit paranoid. The basic goal -- don't let anyone open up access
accidentally. However, the current protections are a bit of overkill. Suppose you've created an `api_key` (sufficient
for `extern/rest.php`) and you want to switch to using `civicrm/ajax/*`. Here are the sysadmin tasks:
1. Enable `authx` (*It's inert otherwise.*)
2. Grant the user permission `authenticate via api key`, or convey the `SITE_KEY` to the user, or disable all `authx_guards`
3. Update the setting `authx_header_cred` or `authx_xheader_cred` or `authx_param_cred` to allow `api_key`
Notably, when this default was first chosen during drafting, the `authx_guards` (step 2) didn't exist. But now they do, and we have even more steps to go through.
This change relaxes the defaults so that step `#3` is not necessary. This arrangement is still fairly paranoid (ie we still have 1+2 -- compared
to `extern/rest.php`, there's still an extra opt-in hoop).
],
];
}
+
+ $s['authx_param_cred']['default'] = ['jwt', 'api_key'];
+ $s['authx_header_cred']['default'] = ['jwt', 'api_key'];
+ $s['authx_xheader_cred']['default'] = ['jwt', 'api_key'];
+
return $s;
};