Unique User id for Google Home actions is not unique - node.js

This gives undefined when requested from device:
originalRequest.data.device.uniqueDeviceId
originalRequest.data.user.userId gives the user id same as getUser().userId, which is not unique. This id changes every time for the user.
Which is the unique Id for a user to identify that the user is unique?

The uniqueDeviceId was never documented by Google and was removed since it could be used to reveal information without the user's permission.
The userId as you've defined it, either through getUser() or through the JSON, is the correct way to uniquely identify a user.
In general, it will be consistent between calls, however, there are a number of cases where it will change. Most notably:
If the user is on a speaker, but does not match any registered voice profile for that device (or there is no registered voice profile on the device). In these cases, the user is "anonymous" and has to be treated that way by the system for their ID.
If the user resets the identifier for the Action (in the same way they might delete a web cookie).
If the user resets their account on a device.
If the user doesn't use your Action for 30 days.
Update
The anonymous userId has been deprecated and will be removed in May 2019. If you need a userId for the user, you can either use account linking or generate it yourself and store it in the user storage object. Neither of these have the same limitations outlined above.

Related

Saving data into user storage from dialogflow fulfillment webhook

I am exploring ways of saving data across conversation in dialogflow from the client library. What I come up with so far are:
Context - you can save the variable in the output context and give it a long lifetime like conv.context.set.
Storing it into an external database like RDIS using the session as a key.
I also found another way using userStorage https://developers.google.com/assistant/df-asdk/save-data#asdk_node_conv_data.
In the case of user storage, is there some gotha I shouid be worry about?
There's no reason to be worried about using userStorage, some of the advantages of using it are:
When the Assistant can match an identity to the user, the contents of userStorage never expire, and only the user or the Action itself can clear it.
You can clear the content of the userStorage field of your Action by
setting the resetUserStorage field of your AppResponse to true.
The userStorage field of your AppResponse object is a string that contains an opaque token supplied by the Action that is saved across conversations for a particular user.
Important: Obtain user consent prior to using user storage. Some countries have regulations that require developers to obtain consent from the user before they can access or save certain information (like personal information) in user storage.
Since you will be entering the user personal storage you'll want to ask permission to the users first.

Management of verificationStatus, accountLinkingStatus, UserStorage, and user's ID in Google Conversational Actions

I am very confused on how I have to handle the verificationStatus and accountLinkingStatus attributes of requests in a Google Conversational Action app that I am working with, specially now that user ID is deprecated.
I need to identify a user, so I need to store data in the UserStorage, only if the user is Verified and gave consent, but since I also have AccountLinking with OAuth, I don't know if it is possible that a user with AccountLinking and not verified could exist, or how to manage or face the user's ID management.
As much as I read the documentation, I cannot understand how the conditions can occur with each other, and if there is mutual exclusion in any case.
A user cannot have a valid account while also being unverified. If the Google Assistant device cannot verify who the user is, it will not send account linking credentials.
However, a user can be verified with voice matching in a way that doesn't require you to have an account.
It's also possible for neither to be true, particularly when a guest is interacting with an action.
Below is a table to show the set of possible states.
Not Verified
Verified
Not Linked
✓
✓
Linked
✕
✓

How to check if phone number is already registered with custom policies adb2c

I am implementing MFA custom policy with Email or Phone option. I want to restrict user to login if phone number is not registered. In my current implementation it is showing a screen to input new number if it is not registered yet , I wanted to restrict user from adding new mobile if not found.
I tried playing with orchestration steps but not able to find the correct output claim to check if user is already registered or not?
You can’t really check per se, AAD B2C has a built in uniqueness checker if you write to the identifier field - signInNames. You can store the phone number in signInNames.phoneNumber and then your uniqueness check is handled by the policy itself when you try to write the value. That prevents any user enrolling a phone number that already exists on another account.

How is Application insight tracking the User_Id?

Im running a Azure Webapp with application insight.
I know Microsoft cant show the real IP (Client_IP) so I add the real IP address to all requests (Ip).
I have a visitor client_id="h9zbt" that in the last 24h is using 48 different client_IP adresses.
The same user also has several real IPv6 adresses.
I like to block this IP from my website, but I think this looks so strange.
Is it really the same user?
How is Application insight tracking the User_Id?
Image link
Usually application insights is automatically opening a session automatically for each user (look for the ai_session key). Therefore the default user scope would be a session scope.
You can override this behaviour by sending a user context if you have some kind of sign-in. (https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context)
I find it likely that it's the same user on the same device, just using several IP-addresses, maybe as an unsuccessful attempt to stay anonymous.
User IDs should persist across user sessions to track how users behave
over time. There are various approaches for persisting the ID.
A definition of a user that you already have in your service.
If the service has access to a browser, it can pass the browser a cookie with an ID in it. The ID will persist for as long as the cookie
remains in the user's browser.
If necessary, you can use a new ID each session, but the results about users will be limited. For example, you won't be able to see how
a user's behavior changes over time.
The ID should be a Guid or another string complex enough to identify
each user uniquely. For example, it could be a long random number.
If the ID contains personally identifying information about the user,
it is not an appropriate value to send to Application Insights as a
user ID. You can send such an ID as an authenticated user ID, but it
does not fulfill the user ID requirement for usage scenarios.
mentioned in Azure doc.
https://learn.microsoft.com/en-us/azure/application-insights/app-insights-usage-send-user-context

How does account validation work?

Usually when you create an account to some webpage they send you an email with a link in order for you to validate your account.
If you click that link then you account is validated and thats the end of it.
How does this work?
Is that url unique for every new user so they know who visited what?
This is not a web service related question, however I can conceptually guide your through what you need to do.
When a user registers their information will probably be captured into some user table in a database somewhere. This user is marked as pending. The system can then generate a unique id i.e. a GUID which is stored next to the user entry in the database. This GUID if properly constructed will be impossible to guess. This GUID is then added as a GET parameter to the URL that you in an email to the user.
For example you might have the URL:
http://example.com/activateuser?confirmuid=5e706449-2cbf-4938-8109-fb564c196d8f
Thus every user will use the same URL with different confirmuid parameter. This URL will then post the confirmuid to the page where you can then use this value to look up the user in the database and then active the user or move it from a pending state to an active state.
Simple right.

Resources