Best practices

Note: this documentation is for the 1.x versions of the JavaScript SDK. The current version can be found here.

Loading the JavaScript SDK

You can load the SDK either synchronously or asynchronously. Depending on your use case, page size and functionality requirements, how you load the SDK may affect how the user perceives their logged in state. Pages with a lot of elements and external JavaScript may cause the loading and initiation of the SDK to be slow and the user may perceive himself as NOT logged in during that period. We suggest that, if you are experiencing this, to load the SDK synchronously and before all other unnecessary requests for page resources.

Initializing the JavaScript SDK

The SDK has many initialization options that directly affect how the SDK behaves in regards to cookies, caching, timeouts and session state handling. Deciding on the correct options and values is extremely important given the use cases you are trying to solve for your application.

There are some best practices and gotchas in regards to these use cases:

Hybrid mobile apps

Hybrid mobile apps are native mobile applications that have implemented the native Schibsted account login API for authentication and serves authenticated content that uses the JS SDK. This solution requires the backend solution that serves this content to know who is logged in. It also implements product access checks that use the JS SDK.

This implementation doesn't support the auto-logged-in functionality built-in by Schibsted account in the SDK between each time the user start the app, meaning that after each application start, the application must exchange a session token via the authentication API and then initiate a session for that user in Schibsted account. Suggested JS SDK initialization for this type of applications are:

cache_notloggedin should be set to FALSE

Because the user wont be served this content without having a session, there is no need to cache the logged out state.

Apps with Varnish support

Apps that have implemented the varnish product access check functionality. This feature uses the JS SDK to set a custom Varnish cookie for the logged in user in the client's domain. This cookie is then sent on every request and intercepted by Varnish, which in turn performs product access checks for the user through a custom Schibsted account API endpoint. Suggested JS SDK initialization for this type of applications are:

cookie: TRUE & varnish_expiration: 28800

This settings enables cookie support and sets the varnish cookie expiration to around 8 hours, which supports basic usage of a paywall enabled application.

Read more about the JavaScript SDK

See also

Help us improve

Did you spot an error? Or maybe you just have a suggestion for how we can improve? Leave a comment, or better yet, send us a pull request on GitHub to fix it (in-browser editing, only takes a moment).

History of this page

Comments/feedback

Do you have questions, or just want to contribute some newly gained insight? Want to share an example? Please leave a comment. SPiD reads and responds to every question. Additionally, your experience can help others using SPiD, and it can help us continuously improve our documentation.