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.
Related
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
✕
✓
A strange situation that I am unable to find other people having to deal with. We are using Microsoft AspNetCore.Identity to handle our authentication. Everything is working fine.
The problem is that for a user to perform certain actions, they MUST get another user to 'sign' that action. This act of signing of course requires that other user to use their user name and password to sign the action.
The issue with this is that the other user's details are readily visible in the request payload. So if I am sneaky, I can open the developer tools in my browser (and hide it), then ask my admin to come and sign my action, and when they have gone i can go to the network tab and see their username and login in plain text!
Of course this is all over https but still, we can't allow one user to see another's sensitive information.
How are we to manage to allow a second userB to 'sign' an action for userA while in user A's active session, while removing the capacity for userA to steal userB's credentials??? Any ideas? (Front end is angular.js)
I imagine it's a big rework, but instead of having the "admin" sign the request on the user's machine, the admin could receive a "user A requires this action to be signed, proceed? [ok] [cancel]" on their account, the action would be stored in the database (perhaps temporarily?) & then all of the sensitive information is kept within each user's session with no cross over.
Then the authentication of who is permitted to approve actions can be handled in the backend via standard identity methods.
The user's "Please wait while an admin signs this action" modal (assumption) could then poll an API to determine the status of the action and then proceed once accepted.
I second #justcompile's answer if you need an authorised and authenticated user to sign/confirm the action, more work but the only secure way.
If you just need a second pair of eyes to confirm you could message a private group or slack channel that only "authorised" people have access to with a one-time URL containing a token (that maybe expires after a period of time too).
Assuming admins only access that channel they can follow the link, the app can validate the token and confirm the action.
Saves a second (admin) user logging in on their own machine and the need to build a workflow and UI etc, but again exposes you to risk if nefarious types get access to the channel or the links sent to it.
Depends on your appetite for risk I guess.
another user performs signing action on your local system? and you are sly?
there is no way to protect their password.
use two factor authentication.
The way this would normally be handled is for the user to request an action. This (unsigned) action-request is recorded in the database. The admin user is able to see this unsigned request in their account, and make an (authenticated) request to sign it. The user would be able to see the status of their request, and whether it has been signed yet.
I have a scenario where basically:
- Authorized (JWT) user access my API
- If user exists, info get synched with DB, if not, gets created
- ETC ETC
My question is, how would I proceed creating this scenario? There's a lot (ok, 4) parameters that should be in the request, but I don't want to polute the scenario with information that can confuse a normal user reading the scenario.
This is what I have:
Scenario: Non Existent user access the API
Given an authorized user access the API
And user does not exist on API database
When user access the API
Then user details are added to API database
And user does exist on API database
A user accessing the api will have: email, auth0_id, nickname and name. Just not sure if I should code those info on the Scenario or somehow do it on the Context file.
Edit:
Can I have some "parameters" to be set IN the Context file, instead of in the .feature file? i.e. On the feature file I say "Non existent user access the application" and inside the Context file, in the function associated with this step, I make sure I create a user that does not exist on the database and so on? Would this be a good way of keeping thinks separated from the .feature scenarios?
Thanks
I would write it like this:
Scenario: API - new user access the API
Given I have a new user
When I access the API with the new user
Then the user is added to the API database
First step would generate the user details and save them in a variable, second would make the call to the api (using the saved variable and generate the JWT) and the last one will check the details in the api.
You can declare new as parameter like:
#Then /^I access the API with the (new|other_user) user$/
Anyway, you should declare it as simple as possible in a manner that has sense to you can that you can easily reuse.
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.
I am working on an iphone app which uses instagram API..and I would like to know the following things..Is it possible to get data from instagram without user logging?If so, what type of data would be retrieved from it?Is it possible to access data of a specified user?Or is it only possible using social networking sites like facebook,tumblr etc?
thanks
Yes, with a valid client id, you can fetch user information for a specific user id. Information available includes name, bio, website, and profile picture. You can also return multiple users' data using the search endpoint.
Take a look at the User Endpoints documented here: http://instagr.am/developer/endpoints/users/
I also suggest reading Do you need to authenticate? section here: http://instagr.am/developer/authentication/
NOTE: by providing a client id instead of a valid user token, you are counting against your own application's 5000 calls per-hour limit. If you plan on having a large user page, you would need to authenticate each user to avoid this limit.