Signin status is CANCELLED when sign in with google home and 'personal results' setting disabled

[florent33700]

I am developing account linking and I have a problem with google home in a certain case. I have a DialogFlow intent that calls this code when i say "log in" :

export function signIn(app) {
  app.ask(new SignIn());
}

I have another DialogFlow intent that has "actions_intent_SIGN_IN" event and calls this code :

export function signInConfirmation(app, params, signin) {
  if (signin && signin.status === 'OK') {
    chatAsk(app, 'A');
  } else if (signin && signin.status === 'CANCELLED') {
    chatAsk(app, 'B');
  } else {
    chatAsk(app, 'C');
  }
}

Everything works fine with google home and google assistant : after logging in, the assistant answers "A".

However, when I disable the "Personal Results" setting on google home, the signin object of the signInConfirmation method has a status equal to 'CANCELLED' and I dont understand why.

I tried to authenticate (with this setting disabled) on applications available on the Google store and they all seem to handle this case: the assistant says something like : "In order to display different content, I need your permission to access your personal informations ... " and it sends a notification in the google home app to change the setting.

Thank you in advance for your help.

[Fleker]

If you don't let the Assistant use personal information, it cannot be used to authenticate your account with other Actions.

[florent33700]

I know but i would like to detect it and inform user to change its settings. But i don’t know how to do !?

[Petter17]

Any workaround on that? I'm facing same issue.

Google just sends a "CANCELLED" status code.

When using this approach you can customize a little bit your Account Linking responses, which is impossible when requiring Account Linking at intent level.

[skezo]

@Fleker

Shouldn't the SignInStatus reflect this or have the auto response indicate the reason why Account Linking is automatically assuming the user has said "no" to signing in?

The current experience is jarring especially if the user thinks they have let the Assistant use personal information. I was scratching my head for 15mins wondering why it was assuming I had said "no" to signing in to an action.

[Fleker]

The behavior that is exhibited is working as it was designed. If folks think that this behavior should be changed, then I can forward that feature request.

[dt1900]

I believe that is what this issue is raising, @Fleker . There needs to be a more discrete differentiation between active, user-initiated cancellation via dialog vs. policy-based cancellation.

Please forward this as a feature request.

[florent33700]

Indeed, for me, the behavior should be changed. However, there must be a workaround because as I said in my first post, some applications on the store handle this case correctly. Or is the environment in which the application is located (draft, alpha, beta, production) can change the behavior?

[eriklindebratt]

I second this. I think this is two-fold;

• a way to check if personal results have been enabled before initiating Account Linking from new SignIn()
• a more detailed description in SignInStatus similar to what @dt-tl describes

@Fleker Is this sufficient for a feature request?

[Fleker]

A feature request has been filed internally.

[eriklindebratt]

Very curious how other people work around this, given the current state.

I've seen that for example Headspace has a specific welcome message when "Personal Results" is turned off:

I'm not sure who you are. Voice Match or Personal Results might be turned off. Would you like to learn how to help me recognize you?

[florent33700]

Another problem: when the user refuses to log in and so the login status is 'CANCELLED' and then he tries to log in again, Google does not manage the new SignIn() and returns "Sorry, I did not get any response. "

[florent33700]

For the moment the only solution I found is to close the application and force the user to restart to authenticate again.

[florent33700]

Here's the answer from Actions On Google support:

if you want to detect if the user enables or disables the "Résultats personnels" feature, you can check the format of his "userId". If this feature is enabled, the userId will be alphanumeric, else it will be a number. For example: Personal Data Enabled "user": { "lastSeen": "2019-01-14T17:59:51Z", "locale": "en-US", "userId": "ABwppHHhiL87jLdl-umMXzUPiWsLWvtBgZ39R-7344BirdrbsKqQ7sSTA_8wUb8V0oKl1O_qqv79G_8" } Peronsal Data Disabled "user": { "lastSeen": "2019-01-14T17:59:51Z", "locale": "en-US", "userId": "15474856490723545489197" } The thing is, as it is explained in this guide , "Anonymous User Identity is deprecated starting from May 31st 2018. The userId property of AppRequest will no longer be included in webhook requests starting from May 31st 2019". You will find there what are the 3 potential migration paths depending on the requirements of your Action.

Knowing that the userId property of AppRequest will no longer be included in webhook requests, if we generate our own userId as the guide advises, we cannot identify users with personal results disabled. As I said in a previous message, some apps on the store clearly detect users with the feature disabled and even send a notification on their phone so they can change the setting. So I think there is another way to detect impacted users.

Concerning the second issue :

Another problem: when the user refuses to log in and so the login status is 'CANCELLED' and then he tries to log in again, Google does not manage the new SignIn() and returns "Sorry, I did not get any response. "

Actions On Google support responded:

a feature request is already opened for that. We'll keep you updated with it.

[ataillefer]

@florent33700 , do you have any news about the latest point?

a feature request is already opened for that. We'll keep you updated with it.

[florent33700]

No News

[ataillefer]

@florent33700 Concerning:

Another problem: when the user refuses to log in and so the login status is 'CANCELLED' and then he tries to log in again, Google does not manage the new SignIn() and returns "Sorry, I did not get any response. "

You might have noticed that it got fixed! Most certainly on the Actions on Google side.

About handling the 'CANCELLED' status, as I was facing the same issue, this is what I'm doing now:

app.intent('Signed In', async (conv, _, signin) => {
  switch (signin.status) {
    // Cancelled/dismissed account linking or Smart Display
    case 'CANCELLED': {
      const hasWebBrowser = conv.surface.capabilities.has(
        'actions.capability.WEB_BROWSER',
      );
      if (hasWebBrowser) {
        ...
      } else {
        // On a Smart Display, if the "Personal results" setting is disabled, the sign in status is 'CANCELLED'
        // See https://github.com/actions-on-google/actions-on-google-nodejs/issues/231#issuecomment-470281010
        // Inform the user that the "Personal results" setting needs to be enabled to sign in
        ...
      }
      break;
    }
    // User successfully completed the account linking
    case 'OK': {
      // Access token might not be available on a Smart Display if the "Personal results" setting is disabled
      if (!isSignedIn(conv)) {
        // Inform the user that the "Personal results" setting needs to be enabled to be signed in
        ...
        break;
      }
      // Welcome signed in user here
      break;
    }
    // System/network error or unknown status
    default:
      signIn(conv, 'Something went wrong during the sign in process.');
  }
});

const isSignedIn = (conv) => Boolean(conv.user.access.token);

So, basically, I'm using the surface's WEB_BROWSER capability to distinguish the Smart Display (auto cancel) form the phone Assistant (manual cancel).

Also note that in the 'OK' case I'm handling the case where the user has signed in on another device, phone typically. Indeed, I've noticed that in this case, when talking to the Smart Display with "Personal results" disabled, the intent responding to the actions_intent_SIGN_IN event receives the 'OK' signin status, but, no access token is available for the user in the conversation (I'm using the OAuth account linking). So we also need to inform the user that she's not signed in before she tries to ask for anything.

Took me quite some tome to understand this :grinning:...

Hope this helps!