You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our client has added some pages that are protected via the standard “who can view this page” settings. When they publish the page(s) they’re added to the index queue, but they then error when the job runs:
[2022-12-22 09:58:30][INFO]
[2022-12-22 09:58:30][WARNING] Job paused at 2022-12-22 09:58:30 [] []
[2022-12-22 09:58:30][ERROR] Call to a member function getRequest() on null {"exception":"[object] (Error(code: 0): Call to a member function getRequest() on null at ***/vendor/silverstripe/framework/src/Security/Security.php:656)"} []
[2022-12-22 09:58:30][WARNING] Job paused at 2022-12-22 09:58:30 [] []
I believe this is because there’s no current member*, so it tries to present the login screen with a session error. No current controller means the session error code path triggers the above error.
How is it best to handle this? For my use case it’s fine for protected pages to not be indexed at all, so I’m thinking I can work around this with the canIndexInAlgolia extension hook, is that what you’d suggest?
Our client has added some pages that are protected via the standard “who can view this page” settings. When they publish the page(s) they’re added to the index queue, but they then error when the job runs:
I believe this is because there’s no current member*, so it tries to present the login screen with a session error. No current controller means the session error code path triggers the above error.
How is it best to handle this? For my use case it’s fine for protected pages to not be indexed at all, so I’m thinking I can work around this with the
canIndexInAlgolia
extension hook, is that what you’d suggest?For users who need protected pages indexed there’s obviously some extra work needed, for example: https://www.algolia.com/doc/guides/security/api-keys/how-to/user-restricted-access-to-data/. If you have any experience of that I’d be interested to hear about it in case I come up against it in future 😄
* the “run as” is correctly set in the queuedjob, but the index job fails to actually run as that user. I think this is due to some fragile code in the queuedjobs module: https://github.com/symbiote/silverstripe-queuedjobs/blob/769332dfd53220a50f585087dfcf94be013177f0/src/Services/QueuedJobService.php#L1098-L1125
The text was updated successfully, but these errors were encountered: