Contents x
    Contextual User Information
      • Print
      Contents

      Contextual User Information

        • Print
        Article summary

        Accessing contextual information about the user

        The X1 Platform provides the following ways to securely retrieve information about a user, X1 Device, or account:

        • Custom URL Parameters

        • .info() X1 JavaScript API method

        This document covers the use of Custom URL Parameters. The full X1 JavaScript API documentation can be found App Requirements.

        Custom URL Parameters must be configured by Comcast. Reach out to your partner manager for more information.

        Custom URL Parameters

        This feature allows information to be passed to an X1 Application about the user or X1 Device as URL parameters.

        Using custom URL params

        URL parameters generally take the form of {CHARIOT:key}. Chariot is an X1 Platform component that runs in the Comcast cloud. When a X1 Application is launched by a user, an instance of Chariot is started with the appropriate launch parameters.

        The template key can be included in a number of different Chariot X1 App launch parameters:

        • url

        • urlComponents.query.key

        • urlComponents.path

        • urlComponents.fragment

        • templateData

        • templateDataRequestHeaders

        Available URL Parameters

        X1 Environment Data

        Description

        Possible Keys

        Examples

        General purpose information about the X1 Device or environment.

        zipCode^
        language
        locale
        deviceHash†
        receiverId
        appId
        timeZone
        partnerId
        deviceCapabilities*

        http://my.url?zipCode={CHARIOT:zipCode}
        http://my.url/partners/{CHARIOT:partnerId}

        ^This is a restricted value. Restricted values are not availble to all apps. Please contact your partner manager for more information.

        *deviceCapabilities - All possible values for this template are listed under deviceCapabilities() . Complex objects are referenced using dot notation, eg. {CHARIOT:deviceCapabilities.hdcp.supportedHDCPVersion}.
        For all deviceCapabilities that are an array of values the template will be resolved as a comma separated values.

        †deviceHash - A unique hash of the deviceId containing only the following characters: [a-z A-Z 0-9]

        Parental Controls

        Description

        Possible Keys

        Examples

        If these templates are used, Chariot will look up the parental control settings for the user and pass them to the X1 App. The restrictionLevel is the lowest level that is locked.
        So if a user locks tvpg, that also means tv14 and tvma are locked as well. The value passed in for tvRestrictionLevel will be tvpg.

        tvRestrictionLevel
        movieRestrictionLevel

        http://my.url?restrictionLevel={CHARIOT:tvRestrictionLevel}

        App Authentication Data

        Description

        Possible Keys

        Examples

        If this template is used, Chariot will look up the a previously stored auth token in Comcast's secure authentication store (called Auth Wallet) for the user, parse the response data to get the selected attribute and return it.

        appAuthData
        selected_attribute

        templateDataRequestHeaders.Authorization = {CHARIOT:appAuthData.userAuthToken}

        Mapped Data

        Chariot is capable of mapping any template value to another value. For instance, if an X1 App has specific model strings that it uses, the mapping between X1 Platform models and X1 App models can be stored in the Chariot system and then the mapped value can be looked up when the template is dereferenced.


        This is accomplished by prefixing any template key with MAP_NAME/, where MAP_NAME is a key that references a map of X1 Platform values to X1 App values.

        Example

        An X1 App can ask to store this map in the Chariot system:

           APP_MODELS
   pace_xg1 = appmodel1
   pace_xg1v3 = appmodel2

        The app can then include the template {CHARIOT:APP_MODELS/deviceCapabilities.deviceMakeModel} in its URL.
        The template the might resolve deviceCapabilities.deviceMakeMode as pace_xg1, then see that it needs to map to APP_MODELS. The value that is actually returned is appmodel1.

        Chariot App Launch Parameters

        Description

        Possible Keys

        Examples

        This is any value which is passed into Chariot as an X1 App launch config.

        n/a

        http://my.url?mutePlayer={CHARIOT:mutePlayer}
        http://my.url?q={CHARIOT:search.query}

        Arbitrary Data

        Description

        Possible Keys

        Examples

        This is a generic parameter that Chariot knows nothing about but was passed in as a launch parameter. The launch parameter must be prefixed with param. whereas the template key is not.The main use for this is storing business logic of a URL in a central configuration, then having different launch points pass in the parameter. This can also be accomplished with urlComponents in most cases. The only catch for urlComponents is that the clients doing the launching need to know the name of a query parameter which can be thought of needing to know business logic of the X1 Application. If the query parameter changes for the X1 App, then all the launch points need to change. With templating, just the centralized config needs to change. It is a small distinction, but templating provides extra flexibility.

        n/a

        http://my.url?q={CHARIOT:myparam} where {"param.myparam":"value"} is passed to Chariot when it is deeplinked into to launch the X1 App.

        Was this article helpful?
        What's Next