passbolt/passbolt_api · error · BadRequestException
Invalid provider data. Expected Google settings.
Error message
Invalid provider data. Expected Google settings.
What it means
Thrown by SsoGoogleService::assertAndGetSsoSettings when the active SSO settings' provider is Google but the settings `data` payload is not a SsoSettingsGoogleDataDto instance. The service requires Google-typed settings data to read the Google client id/secret etc.
Solutions
- Re-save the Google SSO settings through the SSO settings API/admin UI so the data payload is rebuilt as Google settings
- Inspect the sso_settings table data column and confirm it contains Google-specific fields (client_id, client_secret, etc.)
- Verify SsoSettingsGetService hydration/DTO factory maps provider 'google' to SsoSettingsGoogleDataDto, especially after upgrades
- If migrating providers, always submit provider AND matching data together in one settings update
Defensive patterns
Strategy: validation
Validate before calling
$settings = (new SsoSettingsGetService())->getActiveOrFail(true);
if (!($settings->data instanceof SsoSettingsGoogleDataDto)) {
throw new BadRequestException(__('Google SSO settings data is invalid; re-save the settings.'));
} Type guard
if (!($ssoSettings->data instanceof SsoSettingsGoogleDataDto)) {
return null;
} Try / catch
try {
$settings = $googleService->assertAndGetSsoSettings();
} catch (BadRequestException $e) {
// log $e->getPrevious(); prompt admin to re-save Google settings
} Prevention
- Always update provider and data payload together in one settings save
- Re-save settings after version upgrades that touch SSO DTOs
- Never edit the sso_settings data column manually
When it happens
Trigger: The sso_settings row has provider='google' but its serialized data deserializes into a different DTO (e.g. SsoSettingsAzureDataDto or a generic array), typically from a provider change where the data field was not rewritten, or from corrupted/partially-migrated settings data.
Common situations: Admin edited provider field directly in the database without updating the data payload; an import/restore from backup paired Google provider with another provider's data; a version upgrade changed the DTO mapping and legacy data no longer hydrates to SsoSettingsGoogleDataDto.
Understand the failure class
Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.
Related errors
- Invalid provider data. Expected OAuth2 settings.
- Invalid provider data. Expected PingOne settings.
- AccessToken should be an instance of BaseIdToken class.
- $data['error'] (dynamic provider error)
- Invalid provider. Expected Google as provider.
AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17).
Data as JSON: /api/errors/b7d22a148866fde7.
Report an issue: GitHub.
Appendix: source
Thrown at plugins/PassboltEe/Sso/src/Service/Sso/Google/SsoGoogleService.php:88
return SsoProviderFactory::create(GoogleProvider::class, [
'clientId' => $data->client_id,
'clientSecret' => $data->client_secret,
'redirectUri' => Router::url('/sso/google/redirect', true),
]);
}
/**
* @return \Passbolt\Sso\Model\Dto\SsoSettingsDto
*/
protected function assertAndGetSsoSettings(): SsoSettingsDto
{
try {
$ssoSettings = (new SsoSettingsGetService())->getActiveOrFail(true);
if ($ssoSettings->provider !== SsoSetting::PROVIDER_GOOGLE) {
throw new BadRequestException('Invalid provider. Expected Google as provider.');
}
if (!($ssoSettings->data instanceof SsoSettingsGoogleDataDto)) {
throw new BadRequestException('Invalid provider data. Expected Google settings.');
}
} catch (Exception $exception) {
throw new BadRequestException(__('No valid SSO settings found.'), 400, $exception);
}
return $ssoSettings;
}
// HELPERS
}
View on GitHub (pinned to 31c1bbc10f)