Documentation Index

Fetch the complete documentation index at: https://help.frisbii.com/llms.txt

Use this file to discover all available pages before exploring further.

Cookie-based SSO

Prev Next

Cookie-based SSO is a simpler alternative to the OAuth 2.0 flow. When a user is logged in via Frisbii Media, a plenigo_user cookie is set in the browser. Your server reads this cookie and validates it against the Frisbii Media API to confirm the session and retrieve the user profile.

OAuth 2.0 is the recommended approach for new integrations. Cookie-based SSO is suitable for legacy setups or cases where the simpler one-step validation is sufficient and refresh tokens are not needed.


How it works

  1. The user logs in via the Frisbii Media JavaScript SDK (plenigo.SSO().login())

  2. Frisbii Media sets a plenigo_user cookie in the browser

  3. On subsequent page loads, your server reads the plenigo_user cookie from the request

  4. Your server sends the cookie value to the Frisbii Media API for validation

  5. A 200 response confirms the user is logged in and returns the user profile; a 403 means the user is not logged in


Send the cookie value to:

GET https://api.frisbii-media.com/api/v2/user/profile/byCookie
Header: plenigo_user: {cookie_value}

Or use the named API operation:

GET https://api.frisbii-media.com/#!/user/getUserProfileBySessionCookie

Responses:

HTTP Status

Meaning

200

User is logged in. Response body contains the user profile.

403

User is not logged in or cookie has expired.


$cookieValue = $_COOKIE['plenigo_user'] ?? null;
if ($cookieValue) {
    $response = $client->request('GET',
        'https://api.frisbii-media.com/api/v2/user/profile/byCookie',
        ['headers' => ['plenigo_user' => $cookieValue]]
    );
    if ($response->getStatusCode() === 200) {
        $userProfile = json_decode($response->getBody()->getContents());
        // User is logged in — $userProfile->customerId, ->email, etc.
    } else {
        // Not logged in
    }
} else {
    // No cookie present — user not logged in
}

Limitations compared to OAuth 2.0

Cookie-based

OAuth 2.0

Session refresh

No — cookie expires, user must re-login

Yes — refresh token allows silent renewal

Cross-domain support

Limited by browser cookie scope

Full — token passed explicitly

CSRF protection

Not built in

Built in via state parameter

Long-lived background sessions

No

Yes