Developer Platform
  • Home
  • Getting Started
    • General Information
    • Features Overview
    • Security
  • APPs
    • Public Apps
      • Shopify
      • Salesforce
      • Zendesk
      • Google Analytics
    • Build your App
      • Getting started
      • My Apps
      • App information
      • App Parameters
      • App Plugins
      • Add Webhooks
      • Submit your Apps
      • App security
      • Developer Policy
  • Use Cases
    • Copilots
      • Product Catalog sync through API
      • FAQ sync through API
    • Visitor experience
      • Integrating custom buttons into your site
      • Check availability before escalating to iAdvize
      • Authenticated Messaging
        • Introduction
        • Web client-side implementation
          • Authenticated Messaging overview
          • Brief timeline of the integration process
          • How to enable authenticated mode in the administration portal?
          • How to implement the customer authentication backend (token provider)?
          • How to authenticate with iAdvize in client's website?
          • How to deal with activation success or failure?
          • How to logout?
          • Compatibility with Mobile SDK
          • FAQ
        • Web backend implementation
          • Important information and recommendations
          • Signature and Encryption Detailed Process
          • Technical backend implementation
          • FAQ
      • Cross-domain Conversation Continuity
      • Customize replies with Markdown
    • Agent workspace
      • Custom App example and step-by-step tutorial
        • Get Started
        • Work with the Desk
        • Intent / Trigger
        • JWT
        • References
    • Administration
      • Users
        • SAML SSO Authentication - Implementation Guide
        • Create, update and delete users via API
        • Manage the availability of your users with the iAdvize API
        • Integrate the iAdvize conversation panel into an existing tool
    • Data & Analytics
      • Anonymize a conversation or visitor data
      • Create a custom dashboard
      • Find contact data using GraphQL
      • Retrieve conversations data
      • Retrieve messages exchanged within a conversation
  • Technologies
    • GraphQL API
      • Terminology
      • Reference
      • Authentication
      • Schema lifecycle
      • Error Management
      • Pagination
    • REST API (partially deprecated)
      • Statistic
      • Group (deprecated)
      • Call meeting
      • Operator (deprecated)
      • Skill (deprecated)
      • Transaction (deprecated)
      • Visitor (deprecated)
    • Webhooks
      • Reference
      • Guides
    • Desk events
      • Reference
    • Web & Mobile SDK
      • Javascript Web SDK
        • Reference
      • Javascript Callbacks
        • Reference
        • Guides
      • Mobile SDK
        • Fourme (latest)
        • Epoisses
        • Dauphin
        • Cantal
        • 🤝Support Policy
        • 🤔Frequently Asked Questions
    • Custom App
    • External Bot
      • Implementation
        • Configuration flow
        • Conversation flow
        • Conversation objects
      • Configuration
      • FAQ
      • Best practices
Powered by GitBook
On this page
  • Context
  • How is authenticated messaging implemented on the Mobile SDK?
  • Implementation scenarios
  • What is actually happening in the logout within the SDK that could restore the chat the next time the user is logging in again?

Was this helpful?

  1. Use Cases
  2. Visitor experience
  3. Authenticated Messaging
  4. Web client-side implementation

Compatibility with Mobile SDK

Context

Before starting the integration of authenticated messaging, you need to make sure to plan the deployment of the feature depending on your use case.

If you are planning on deploying this feature on the web and on the mobile SDK, there are a few things you need to know:

  • Will end-users authenticate on the app AND on the website?

  • If so, will you deploy authenticated messaging at the same time on the mobile app and the website?

How is authenticated messaging implemented on the Mobile SDK?

There is a full section dedicated to Mobile SDK where you will find the information regarding authenticated messaging.

Basically, you can choose between multiple authentication options:

Anonymous

For an unidentified user browsing your app.

Simple

For a logged in user in your app. You must pass a unique string identifier so that the visitor will retrieve his conversation history across multiple devices and platforms. The identifier that you pass must be unique and non-discoverable for each different logged-in user.

Secured

Important: if you want to start using the secured mode as a second step, we strongly advise that you implement the anonymous mode as a first step. Indeed, if you choose the simple mode first, your users will loose all their conversation history the day you decide to switch to the secured mode. If however you implemented the anonymous mode, they will be able to keep it.

Implementation scenarios

Context
Actions

I want to launch on web only (no Mobile SDK used)

I want to launch on web only (and I do use the Mobile SDK at the same time but I don't want the feature there)

I want to launch on Mobile SDK only (no Web used)

I want to launch on Mobile SDK only (and I have the chat on my website but I don't want the feature to be deployed there)

I want to launch on both: web and Mobile SDK at the same time.

What is actually happening in the logout within the SDK that could restore the chat the next time the user is logging in again?

This is dependent on the type of activation that was made.

If the user was logged in anonymously, then the SDK keeps some information during the logout.

This is designed so that if an anonymous visitor starts chatting then logs into your app, the SDK calls to logout / activate (simple or secured) would keep the user's ongoing conversation / conversation history.

If the user was logged in "non-anonymously" (either with simple auth or secured auth), then the logout clears the whole user session. Please note however that if you log a user with an “already known" user id, the visitor session (history, parameters) will be pulled back. This is designed for chat history continuity across devices.

1. activate anonymous
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured)
==> the chat history is retrieved 

1. activate (simple or secured), user-id = foo
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured), user-id = foo
==> the chat history / gdpr conset etc... are retrieved 

1. activate (simple or secured), user-id = foo
2. starts a chat
3. logout (sdk keeps visitor info)
4. activate (simple or secured), user-id = bar
==> a new user session starts

PreviousHow to logout?NextFAQ

Last updated 1 year ago

Was this helpful?

Use it in conjunction with your in-house authentication system. You must pass a JWE provider callback that will be called when an authentication is required, you will then have to call your third party authentication system for a valid JWE to provide to the SDK. For a full understanding of how the secured authentication works in the iAdvize platform you can refer to this .

Follow this - nothing specific to keep in mind regarding the Mobile SDK

Follow this AND make sure the iAdvize hybrid flag is activated (ask an iAdvize TAM). This will allow you to use the on Mobile SDK while having the feature deployed for your website

Follow this (choose the secured option) - nothing specific to keep in mind regarding the web

Follow this and choose the secured option

Follow this for the web part and this for Mobile SDK (choose the secured option)

section
documentation
documentation
simple mode
documentation
documentation
documentation
documentation