seamus_lee → created an issue.
I have re-rolled the patch taking into account the feedback in #14. I am not sure what to do about the tests as I'm not sure how you can mock a secured v non secured http request
seamus_lee → created an issue.
Just flagging that I have tested this with the change I mentioned above on a client site and login works successfully. One thing I would suggest is that this should probably be done as a 4.x version given the change in the SDK version and also we need to highlight in the release notes that the auth0_cookie_secret needs to be configured probably prior to the upgrade otherwise can get a fatal error
Thanks for the work @polynya and @aneek
One thing I was noticing when comparing the previous set of changes is that I don't think the offline access was set up correctly and I think this solves the issue as per https://auth0.com/docs/secure/tokens/refresh-tokens/get-refresh-tokens you need to specify offline_access in the scopes if your permitting offline access
```
diff --git a/src/Controller/AuthController.php b/src/Controller/AuthController.php
index 1a93a6f..95d389c 100644
--- a/src/Controller/AuthController.php
+++ b/src/Controller/AuthController.php
@@ -231,7 +231,7 @@ class AuthController extends ControllerBase {
$this->redirectForSso = (bool) $this->config->get(AuthController::AUTH0_REDIRECT_FOR_SSO);
$this->offlineAccess = (bool) $this->config->get(AuthController::AUTH0_OFFLINE_ACCESS);
$this->currentRequest = $request_stack->getCurrentRequest();
-
+ $scopes = explode(' ', AUTH0_DEFAULT_SCOPES);
$sdk_configuration = new SdkConfiguration([
'domain' => $this->helper->getAuthDomain(),
'clientId' => $this->clientId,
@@ -239,6 +239,7 @@ class AuthController extends ControllerBase {
'cookieSecret' => $this->cookieSecret,
'redirectUri' => "$base_url/auth0/callback",
'persistUser' => FALSE,
+ 'scope' => ($this->offlineAccess ? array_merge($scopes, ['offline_access']) : $scopes),
]);
$transient_store = new SessionStore($sdk_configuration);
$sdk_configuration->setTransientStorage($transient_store);
```
I have attached a patch that I worked on for a client site that had this same problem, It is slightly different in that I stuck with using the database but I instantised 2 database arrays as per civicrm entity which provides d9 views integration and modified the database query appropriately. That being said I think with the API or database way it is a bit of 6 of 1 half a dozen of the other, I'll let the maintainers decide which way they want to go.
The applied patch solves this for us and seems to be consistent with the other services
seamus_lee → created an issue.