PHPackages                             stylers-llc/chopra-account-php-sdk - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Authentication &amp; Authorization](/categories/authentication)
4. /
5. stylers-llc/chopra-account-php-sdk

ActiveLibrary[Authentication &amp; Authorization](/categories/authentication)

stylers-llc/chopra-account-php-sdk
==================================

SDK for Chopra Single Sign On system.

1.1.0(7y ago)0392MITPHPPHP &gt;=5.4

Since May 13Pushed 7y ago3 watchersCompare

[ Source](https://github.com/stylers-llc/chopra-account-php-sdk)[ Packagist](https://packagist.org/packages/stylers-llc/chopra-account-php-sdk)[ Docs](https://github.com/stylers-llc/chopra-account-php-sdk)[ RSS](/packages/stylers-llc-chopra-account-php-sdk/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependenciesVersions (6)Used By (0)

Server Requirements
===================

[](#server-requirements)

- PHP &lt;= 5.4
- PHP Memcache module
- OpenSSL module
- PECL Hash &lt;= 1.1 ([*http://php.net/manual/en/function.hash-hmac.php*](http://php.net/manual/en/function.hash-hmac.php))
- PHP CURL module

Structure of the SDK
====================

[](#structure-of-the-sdk)

Client.php: Client-side main class. This is the only class that needs to be instantiated on each run where a user session is required.

Api.php: It is responsible for the API connection and communication. No instantiation is required, it is done by Client.php.

Session.php: It is responsible for the management of the user session, no instantiation is required, it is done by Client.php.

It uses memcache connection for session management; so the php\_memcache module needs to be enabled on the server.

There is no autoloader in the SDK (yet), so all three files are needed to be put in “require” clause on each run, or to be loaded by a private auto-load solution.

Operational process
===================

[](#operational-process)

Standard Integration Flow
-------------------------

[](#standard-integration-flow)

Flow chart of how to integrate this SDK into your system can be found [here](https://choprasso-public.s3.amazonaws.com/uploads/standard_integration_flow.png).

Instantiation
-------------

[](#instantiation)

It is necessary to instantiate the Client class with the proper parameters on each run where a user session is required (in middleware or in the init, or during bootstrap):

```
$client = new Client([
	'client_key' => '[your_client_key]',
	'client_secret' => '[your_32_chars_client_secret]',
	'session_host' => '[memcache_host_name]',
	'session_port' => '[memcache_port]',
	'endpoint_basepath' => 'http://account.chopra.com/',
	'api_key' => '[api_secret_key]',
	'api_endpoint' => 'http://account-api.chopra.com/',
    'cookie_domain' => '[cookie_domain]'
]);
```

#### Client Parameters

[](#client-parameters)

- **endpoint\_basepath:** only necessary in dev environment – the live domain is predefined into the SDK.
- **api\_endpoint:** api\_endpoint is only necessary in dev environment – the live domain is predefined into the SDK.
- **cookie\_domain:** cookie domain is optional. if not provided, sdk generates it from $\_SERVER request parameters. it must be the main domain of your system. if you use multiple subdomains for the same authentication system, than you should provide the main domain without subdomain. if your entire site is on a subdomain you have to provide the full domain with subdomain, eg. ayurveda.chopra.com

**!Notice:** Code above and session check below with redirection have to run ONLY when http request is initiated by a browser, or in other cases where it’s necessary. Do not include it when your system is requested by a cron job, or running in CLI.

Session check
-------------

[](#session-check)

Needs to be checked on each run: which user is stored in the SSO session.

This can be done as follows:

```
try {
	// it throws an exception if there is no cookie or it is wrong or it has a invalid session ID
	$ssoUser = $client->getUser();
} catch (SSOAuthException $e) {
	// in this case you should redirect to SSO check URL which restore the user session from an existing session ID or if the user is not logged in (there is no existing session) then creates a guest session
	header('Location: ' . $client->getCheckUrl('http://[yourhost.tld]'));
    // you have to provide the redirect URL as parameter where the SSO should redirect back to. It can be any URL where this code snippet runs again. You can redirect to any URL because this code should be executed at each runtime.
}
```

Redirect
--------

[](#redirect)

After redirection the response from SSO have to be checked and processed, like any other ouath / sso solution does. This is done by the getUser method automatically (mentioned in section 3.2 above). When the getUser method returns member type user, local user process can be done with it (store in local database, connect with existing local user, store in global scope for runtime, etc)

When returned user array is guest type, it means there is no logged in SSO user, and the returned array looks like this: \[ '\_auth\_type' =&gt; 'guest' \]

Initiating the SSO Login process
--------------------------------

[](#initiating-the-sso-login-process)

After finishing the above process, the client class-object method memberLoggedIn() makes it possible to check whether it is a member type session or a guest type session, and then write out a link on the sso login page so that the user can start the process:

```
if (!$client->memberLoggedIn()) {
	// we display an SSO login URL.

	// for the getLoginUrl params you have to give a redirect URL also
	echo 'Login with SSO';
}
```

Following the redirect to the SSO and a successful login or registration there, when returning to the page we get a full user array in $ssoUser, with all the data of the user. (The try-catch program branch, mentioned in section 3.2 above, needs to happen on each run so that the $ssoUser variable will be present all the time.)

**!Notice:** method memberLoggedIn can be called only after a successful session checking. If code in section 3.2. returns an SSOAuthException, then you have to do a redirect to check url as it is described above.

Logout
------

[](#logout)

The getLogoutUrl() method of the client class returns a URL, and that is where the browser needs to be redirected. This method also expects a redirect\_url parameter.

```
if ($client->memberLoggedIn()) {
	echo $client->getLogoutUrl('http://[yourhost.tld]');
}
```

Profile update on SSO page
--------------------------

[](#profile-update-on-sso-page)

The getProfileEditUrl() method of the client class returns a URL, and that is where the browser needs to be redirected. This method also expects a redirect\_url parameter to redirect the browser to after the profile modification is done.

```
if ($client->memberLoggedIn()) {
	echo $client->getProfileEditUrl('http://[yourhost.tld]');
}
```

Initiating the SSO Social Login process
---------------------------------------

[](#initiating-the-sso-social-login-process)

### Local social authentication

[](#local-social-authentication)

As a first step, the locally linked social authentication needs to be performed. This can be either facebook or google.

### Redirection to the SSO Social login page

[](#redirection-to-the-sso-social-login-page)

Next, the user needs to be redirected to the sso social login page, with the social data as parameters. The example below will not run, and neither will the code snippet found in example.php, because it requires the social ID and social Token acquired by the local social authentication.

```
if (!$client->memberLoggedIn()) {
	echo 'Login with SSO';
	echo 'Login with social';
}
```

Parameters of getSocialLoginUrl:

1. redirect\_url, the SSO redirects here after the successful login
2. social network type, options: google, facebook
3. In php array: \['id' =&gt; '{social\_id}', 'token' =&gt; '{social\_token}' \] – obviously, social id and social token must be substituted with the proper values. These two values are required, can not be null or empty, otherwise SDK will raise an exception.

The processing workflow following the redirect is the same as in the case of a normal login.

After the local social auth you can redirect the user back to the return URL what you get back from getSocialLoginUrl method.

Create Sage User ID for SSO User
--------------------------------

[](#create-sage-user-id-for-sso-user)

By default User datas returned by getUser method contains the Sage User ID for the user. But if not, you can easily create a Sage User ID for an SSO user by a simple API call to SSO API endpoint. If user not exists in Sage system, it will be automatically created. You can do this with the SDK like this:

```
        $postData = [
            'zip_code' => '1234', // any zip code, required by Sage system
            'user_id' => '342567' // SSO User ID
        ];

        $sageUser = $client->api()->makeCall(
            'mas_user_id',
            'POST',
            [],
            $postData
        );
```

###  Health Score

29

—

LowBetter than 60% of packages

Maintenance20

Infrequent updates — may be unmaintained

Popularity12

Limited adoption so far

Community10

Small or concentrated contributor base

Maturity62

Established project with proven stability

 Bus Factor1

Top contributor holds 96.7% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~242 days

Total

5

Last Release

2682d ago

### Community

Maintainers

![](https://www.gravatar.com/avatar/917ff2a7eae0addaed33bb1669b423e54922e652a432bf0c98ad07c7a200de2a?d=identicon)[gabor-nagy-stylers](/maintainers/gabor-nagy-stylers)

---

Top Contributors

[![gabor-nagy-stylers](https://avatars.githubusercontent.com/u/18379085?v=4)](https://github.com/gabor-nagy-stylers "gabor-nagy-stylers (29 commits)")[![szeleistylers](https://avatars.githubusercontent.com/u/19349233?v=4)](https://github.com/szeleistylers "szeleistylers (1 commits)")

---

Tags

sdk

### Embed Badge

![Health badge](/badges/stylers-llc-chopra-account-php-sdk/health.svg)

```
[![Health](https://phpackages.com/badges/stylers-llc-chopra-account-php-sdk/health.svg)](https://phpackages.com/packages/stylers-llc-chopra-account-php-sdk)
```

###  Alternatives

[happyr/linkedin-api-client

LinkedIn API client. Handles OAuth, CSRF protection. Easy to implement and extend. This is a standalone library for any composer project.

1991.6M12](/packages/happyr-linkedin-api-client)[symfonycorp/connect

SymfonyConnect SDK

9245.2k2](/packages/symfonycorp-connect)[surfoo/geocaching-php-sdk

Geocaching PHP SDK

143.4k1](/packages/surfoo-geocaching-php-sdk)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
