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

  1. Re-save the Google SSO settings through the SSO settings API/admin UI so the data payload is rebuilt as Google settings
  2. Inspect the sso_settings table data column and confirm it contains Google-specific fields (client_id, client_secret, etc.)
  3. Verify SsoSettingsGetService hydration/DTO factory maps provider 'google' to SsoSettingsGoogleDataDto, especially after upgrades
  4. 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

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


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)