I am using Dialogflow to create a chat bot. How do I maintain a user model within a chatbot system?
I want to have a different user model saved for each user in a group. The user model should store the user’s name, personal information it gathers from the dialog, and the user’s likes and dislikes.
With this information, I would like to add personalized remarks from the user model to the dialog engine.
You need some database to story User information.
as per Dialogflow
It's helpful to think of API.AI as just that - an API that you use to
parse user intent from natural language queries. If you have custom
business logic, platform-specific formatting requirements, or need to
integrate with external data stores, it would be better to create your
bot from scratch in code, and make calls out to API.AI in order to
parse inbound queries. API.AI isn't a bot-building platform, but a
Natural Language Understanding platform.
for more Information click here
you can use web-hooks which hits your controller function and run logics which you want like save information.There is one Object like response in which all information inside there
It depends how long you wish to maintain the information about the user and what platform, if any, you're integrating Dashbot with.
Using just the Dashbot framework, one good way to maintain the user information is through the parameters available to a Context. This will be retained during the entire conversational session.
However, if you want to maintain this information between sessions, you'll need to handle this in your fulfillment - in particular, you'll have to save it in a permanent store (such as a database) against a userid if one is provided for your integration.
Related
Using the firebase platform..
I would like to save some custom information about a user once they register.. and just for examples sake, lets say his/her favorite color.
So far when I register a user this is the only meta data I get
What options are at my disposal to get this done?
You have two options:
1 - Use Custom Claims
You can save additional data to the access token of the user. You can read that data directly from the user in the frontend and also in all database rules. I would recommend to use this for basic auth data like isAdmin or isRole if there are not much data to save. The reason for that is that it's quite limited in the amount of data you can save. Because it's saved in the token it has to be small so you should not save to much in it. You can find more about it here. You should edit this fields by a firebae cloud function using the admin sdk.
2 - Use one of the databases
I see it very often and it's quite common in Firebase to store such additional user data into one of the Firebase databases. You can make those 1000% securely by allowing only the user to write and read then or only to read depending on your needs. If you want to save more than just simple data I would recommend this. One reason more is if any other user like admin needs that data from another user you would not be able to get it by using the first option. It is also much easier to do it when the user needs to save data for himself and by himself. With the first version you would always need to involve cloud functions.
I very often use combination of both where I save such data like isAdmin to the custom claims but all other like nickname or some settings like language to a database. With the database I can also make it very easy to search through all users when you are an admin.
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I couldn't find an API for api.ai. The requirement is to add intents and train the model programmatically through an ajax API call.
Yes, API.AI has a REST-like API that lets you manipulate Intents, Entities, user specific and session Entities, Contexts, and even execute Queries.
You'll need to read details about the developer token and the version string to use, but documentation about getting, creating, updating, and deleting intents, as well as the layout for the intent object, are available at https://api.ai/docs/reference/agent/intents
If you're familiar with REST-like APIs, it is pretty straightforward.
I have an app where people login to our site, search for FB groups based on keyword, and then download a text file of UIDs (generated by the API, not by scraping), for the purpose of creating a custom audience in the Power Editor and uploading it back.
Is that allowed?
It is okay to do so, as long as it is strictly for the functionality for your app and your users that will be downloading the lists of ids have agreed to keep them confidential. These are the specific items from the Facebook platform policy which address what you cannot do with user ids:
II
6) You will not directly or indirectly transfer any data you receive from
us, including user data or Facebook User IDs, to (or use such data in
connection with) any ad network, ad exchange, data broker, or other
advertising or monetization related toolset, even if a user consents
to such transfer or use. By indirectly we mean you cannot, for
example, transfer data to a third party who then transfers the data to
an ad network. By any data we mean all data obtained through use of
the Facebook Platform (API, Social Plugins, etc.), including
aggregate, anonymous or derivative data.
7) User IDs for any purpose outside your application (e.g., your
infrastructure, code, or services necessary to build and run your
application). Facebook User IDs may be used with external services
that you use to build and run your application, such as a web
infrastructure service or a distributed computing platform, but only
if those services are necessary to running your application and the
service has a contractual obligation with you to keep Facebook User
IDs confidential.
Make sure that your app doesn't break either of those rules or any other rule in the Platform Policy.
I'm building a service which can be used anonymously, however the user has the ability to share content on his\her Facebook and\or Twitter profiles. Upon authorizing the applications I wish to store basic information about the users and link it to the content they are sharing.
Usually services require authentication prior to usage, which solves this problem, however in my case authentication comes at the very last stage and it's split into 4 paths:
[Facebook + Twitter]
[Facebook alone]
[Twitter alone]
[Nothing]
However doing the above will create redundant data in the database i.e. I will have the Facebook information and Twitter information in separate tables with no linkage between them and no relation to the post.
What's the best approach to prevent this? The solution is on the data modeling level? Or on the code level? Or both?
Has this been done before?
I have created a flow chart of how the merging of account data can be done, however this process might create overhead on the database level as it will require searching for entries using the very long FacebookID \ TwitterID.
If extra information is required please state it in a comment.
Thank you
The way I would handle this is to separate the concept of user identity from the concept of authentication used by your application. For example, at the data model level, have Users table store basic user information and have Authentications table that stores user credentials/tokens associated with a particular Authentication Provider.
At the code level, if you are planning to stick with third-party authentication, I would recommend looking into building a layer that can shield your application from having to deal directly with various OAuth providers.
In Ruby/Rails world, this is accomplished by a combination of Devise that manages user identities (it also allows to have built-in username/password authentication, but it does not sound like you are interested in that) and OmniAuth that delivers authentication against multiple providers.
An example application incorporating both is available here: Devise + OmniAuth.
Finally, RailsCast on the subject is here: OmniAuth Part 1
I realize that you may not be working in Ruby/Rails, but these materials may provide you with inspiration for the architecture you are trying to achieve.