I am building an agent that will initiate a conversation with a caller. After asking basic information the agent will need to get a security phrase or secret from the caller to establish they are who they say they are.
I cannot get the agent to capture the answer after the agent asks, "what is your security phrase".
Any ideas or suggestions?
Add a custom follow-up to the intent requesting the security phrase.
In the custom fullow-up training phrases, insert a parameter associated with the #sys.any entity that allows you to capture any sentence.
In the fullfilment call the parameter and verify if the security phrase given by the user is the correct one.
But be careful, this solution is simple but not always safe. The follow-up helps you to give the right direction to the conversation, but if the user says a sentence that matches an intent without input context, the conversation could accidentally continue in a wrong way. This is because using #sys.any makes difficult (or impossible) to throw a fallback intent for an unexpected response.
Related
whole day was trying to create a session entity for my intent with actions-on-google-nodejs. Unfortunately without any success.
I believe that the this library doesn't support entities in any way, which is a bit sad. Am I right?
During my research I found this amazing post which is explaining how to create and manage entities through API , however they are using nodejs-dialogflow
Was considering using both libraries actions-on-google-nodejs and nodejs-dialogflow, but than when I'm catching the intent with actions-on-google-nodejs the second library (nodejs-dialogflow) will not have idea about the content and etc.
After further research I found the API documentation for sessions.entityTypes The "Try this API" works amazing with Google OAuth 2.0, however don't know how to authorize my server (express.js) with Google OAuth 2.0. I tried with API key but all the time I'm getting the following error:
{
"error": {
"code": 401,
"message": "Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
"status": "UNAUTHENTICATED"
}
}
Any suggestions how I can create a session entity for my intent?
The reason why I'm trying to use session entity is because the entity will change every couple of days and don't want to update the entity in dialogflow. My idea is to store it in DB (firebase) and on intent will validate if it match any of the values.
Keep in mind that the Session Entity must be set to the values you want before it is expected to be matched in an Intent. You probably should do this right when your Action starts, in your case. So if you have your "Welcome" intent, and a "State Option" intent, where the "Option" entity is in the "State Option" intent, you should update "Option" in the "Welcome" intent. You can't do it in the "State Option" intent, because it needs to have matched the Entity already.
The two libraries do completely different things, and can work well together. You will need to get the session path from the original request body, which you can get from conv.request using the a-o-g library, and the entity path, which you'd have to set in some way.
The nodejs-dialogflow library is just a wrapper around the REST API that you've also found (actually, probably around the gRPC equivalent, but it doesn't matter). The big thing that it does, however, is the work that will convert the secret key that you get from the service account into an access token that you need to send with every request. If you're not familiar with Google's OAuth 2 implementation, this can make things a lot easier, although it is certainly possible to do this yourself.
Finally, while the idea is sound and will work, remember that this will take some time during an Intent and that the user is waiting for a reply. Since this data will update infrequently, and for everyone, you may wish to use a similar API to just change the Entity periodically. This process could be something you trigger out of a scheduled (cron) job and have a way to trigger it manually if you need to.
I have the following intent and followup intents for a user login process:
How can I set a while loop for this login process in order to continue asking user email while user enters email address incorrectly and after he/she enters it correctly the getting password intent triggers?
In my cases after 2 incorrect entry, api.ai will response "Not Available".
Forcing users to respond to a question without giving them recourse to cancel, move to another part of your conversational interface or speak about another subject is user-hostile and I'd recommend doing exactly what Actions on Google forces you to do in this situation: end the conversation after a few failed attempts.
Conversational interfaces are best thought of as designing actual conversations. In a normal conversation asking the same question multiple times regardless of what someones says to you would largely be considered annoying at best. Consider revising your Dialogflow agent to allow logged-out conversations explaining to the user what your agent can offer and why login is required for certain features. If the user repeatedly asks for a feature that requires login but refuses to do so, the conversation should end.
Another note here: I'd recommend against using passwords through conversational interfaces. Most conversational platforms have a way to sign in (e.g. Google Assistant/Actions on Google) or you can safely assume the user is using a device where they have access to a web browser as well (Slack) and you can use a system like OAuth to properly authenticate users.
I am currently developing a strategy for Dialogflow on https://passportjs.org.
From what I've learnt, Dialogflow doesn't authenticate users. So I'm thinking about making a strategy (for passportjs) that identify users from every plateform differently (analyse the originalRequest differently for each plateform).
For example, the Telegram originalRequest has this field:
originalRequest.data.message.from.id
The Telegram says this field is a:
"Unique identifier for this user or bot"
So I think it is safe to use it for authentication and identify every intent of my users fulfilled by my webhook.
I was wondering about the actions-on-google authentication and I found the field originalRequest.data.user.userId.
The documentation says:
"Users can reset this identifier, so don't store important user data keyed off this identifier, because once it's reset, that information is no longer accessible by the user."
So the only reason to not trust the userId is because it can be reset? At the end of the documentation it says:
User ID lifetime - User IDs are reset automatically after 30 days of inactivity or if users unlink their accounts on the device.
And:
"If a registered user's voice isn't recognized by the device or no registered voice exists, then a different ID is used that is unique for just that conversation."
How to differentiate users from one other? Can some IDs be recycled?
The best way to differentiate users from each other is to use the userId field, as you've determined. On the AoG platform, the userId is meant to be used somewhat like a web cookie can be used - if you see it again, you are assured that this is the same user that used it last time. But if you see a new one, you have to assume that you've never seen this user before, even if it means they deleted the cookie.
To be clear - most of the time, the UserId will remain the same and you can expect returning users to have the same ID. This won't be true in only three cases:
They have reset the ID for this Action. So they have deliberately chosen to start over.
They didn't use the Action for 30 days, in which case it makes sense to treat them as a brand new user anyway in most cases.
They were not recognized as a normal user of this device, so they are treated anonymously. (This is the equivalent of the clunky "Do not remember me on this machine" setting you see on websites, which forces a session cookie rather than a persistent cookie.)
The phrasing is poor in the documentation - I think it is meant to remind developers that the user is ultimately in charge of their privacy. And Google both forces you to do the same and adopt policies that do so.
IDs will not be recycled. In fact, they won't even be re-used between different Actions, even for the same Assistant account.
Summary: If you see the same UserId, you can trust it is the same user you saw before. If you see a new one, assume they are a new user.
If you want a more robust way to identify users, you might consider using Account Linking which puts you in control of the identifying token. But that has significant additional overhead.
Be careful when using other authentication methods - Google limits how you're allowed to use them as part of an Action, and expressly forbids them in some cases. See the General Policies for details.
I'm in the process of adopting DDD concepts for designing our next projects, and more specifically CQRS.
After reading a LOT of stuff I'm now trying to implement a simple Proof Of Concept.
The thing is I'm stuck right after I started :p
I'm trying to apply this approach to a simple user registration process, where steps are:
User fills the registration form & submit the request
The app creates the user
The app authenticates the user (auto log in)
The app sends a verification email to the user
The app redirect the user somewhere else with a confirmation message
From an implementation point of view, what I get so far is:
The controller action maps the request data to a RegisterCommand object
The controller action asks the Command Bus to handle the RegisterCommand
The command handler (UserService) "register" method creates a new User object (whether by a new command or a factory object)
The model raises a RegisterEvent
The command handler asks the repository to store the new user object
That's it, the controller action doesn't know about any of that.
So, my guess is, since everything in this context HAS TO be done synchronously (except for the email sending), I can use a direct/synchronous command bus, and in the controller action, right after the command bus invocation, I can query for a read only User (query database) and if it exists assume that everything went well, so I can give the user a confirmation message.
The automatic log in process being handled by an Event Handler.
Assuming that this is correct, what if something goes wrong, how to inform the user with the correct information ?
A common example is often used in articles we can find over the internet: A customer pays his order by using an expired credit card. The system accepts the request, informs the user that everything is OK, but the user receives an email a few minutes later telling him that his order could not be processed.
Well, this scenario is acceptable in many cases, but for some other it is just not possible. So where are the examples dealing with these use cases ? :p
Thank you !
I think this registration use case is closer to the paying for an order use case than you think.
Most of the CQRS thought leaders suggest validating on the read side before issuing a command, thus giving your command a higher probability of success.
If the validation fails on the read side, you know how to handle this - make the user pick another name before you even send off the registration command. If validation succeeds, send the command - now you're talking probably a few hundred microseconds AT MOST where another user could've come in and taken the same username between the time you validated the command and sent it off. Highly unlikely.
And in the very rare case when that does happen, you act in the same as way as the expired credit card example - the next time the user logs in, you present them with an explanation and a form to submit a new username - or send them an email saying "hey - someone else has that username, please click here to select a new one". Why does this work? Because you have a unique ID for that user.
Look at a user registration page like Twitter. As soon as you enter a username, it does a little Ajax call and says "nope, this is taken" or "this one is good!" That's pre-validation.
I hope this helps!
The problem with contrived examples is that you can change your mind about how the "domain" functions, so there's little use in discussing this example in particular. The basic premise you seem to forego is that we must assume that things are just going to work. Everything else is about risk and mitigating it. Taking this example, if I ask you, what if I lost 1 user registration in 100000? What if I lost 1 out of 10? Why would that happen? Do I have bigger problems at that point in time? Would future users be likely to register again when the system comes back online and works as expected? When would that be? What if we monitored our quality of service and prevent users from registering because we can't assure the quality they've come to associate with our brand? What if the server exploded, or the datacenter got nuked? Do we want to protect against that? You see, there is no right answer. Just various shades of grey. So how do we mitigate the risk? We could make things synchronous but that is only a guarantee at that limited point in time. What if I had to restore a backup that's 2 hours old (e.g. because the disk corrupted)? That's 2 hours of registered users lost (maybe). These things happen ... I just wanted to point out the relativity of what I consider a false sense of security. Mitigate it, invest in what you can't afford to lose, make sure you have a good audit trail. Probably not the answer you were looking for ...
Applications send out emails to verify user accounts or reset a password. I believe the following is the way it should be and I am asking for references and implementations.
If an application has to send out a link in an email to verify the user's address, according to my view, the link and the application's processing of the link should have the following characteristics:
The link contains a nonce in the request URI (http://host/path?nonce).
On following the link (GET), the user is presented a form, optionally with the nonce.
User confirms the input (POST).
The server receives the request and
checks input parameters,
performs the change,
and invalidates the nonce.
This should be correct per HTTP RFC on Safe and Idempotent Methods.
The problem is that this process involves one additional page or user action (item 3), which is considered superfluous (if not useless) by a lot of people. I had problems presenting this approach to peers and customers, so I am asking for input on this from a broader technical group. The only argument I had against skipping the POST step was a possible pre-loading of the link from the browser.
Are there references on this subject that might better explain the idea and convince even a non-technical person (best practices from journals, blogs, ...)?
Are there reference sites (preferably popular and with many users) that implement this approach?
If not, are there documented reasons or equivalent alternatives?
Thank you,
Kariem
Details spared
I have kept the main part short, but to reduce too much discussion around the details which I had intentionally left out, I will add a few assumptions:
The content of the email is not part of this discussion. The user knows that she has to click the link to perform the action. If the user does not react, nothing will happen, which is also known.
We do not have to indicate why we are mailing the user, nor the communication policy. We assume that the user expects to receive the email.
The nonce has an expiration timestamp and is directly associated with the recipients email address to reduce duplicates.
Notes
With OpenID and the like, normal web applications are relieved from implementing standard user account management (password, email ...), but still some customers want 'their own users'
Strangely enough I haven't found a satisfying question nor answer here yet. What I have found so far:
Answer by Don in HTTP POST with URL query parameters — good idea or not?
Question from Thomas -- When do you use POST and when do you use GET?
This question is very similar to Implementing secure, unique “single-use” activation URLs in ASP.NET (C#).
My answer there is close to your scheme, with a few issues pointed out - such as short period of validity, handling double signups, etc.
Your use of a cryptographic nonce is also important, that many tend to skip over - e.g. "lets just use a GUID"...
One new point that you do raise, and this is important here, is wrt the idempotency of GET.
Whilst I agree with your general intent, its clear that idempotency is in direct contradiction to one-time links, which is a necessity in some situations such as this.
I would have liked to posit that this doesn't really violate the idempotentness of the GET, but unfortunately it does... On the other hand, the RFC says GET SHOULD be idempotent, its not a MUST. So I would say forgo it in this case, and stick to the one-time auto-invalidated links.
If you really want to aim for strict RFC compliance, and not get into non-idempotent(?) GETs, you can have the GET page auto-submit the POST - kind of a loophole around that bit of the RFC, but legit, and you dont require the user to double-optin, and you're not bugging him...
You dont really have to worry about preloading (are you talkng about CSRF, or browser-optimizers?)... CSRF is useless because of the nonce, and optimizers usually wont process javascript (used to auto-submit) on the preloaded page.
About password reset:
The practice of doing this by sending an email to the user's registered email address is, while very common in practice, not good security. Doing this fully outsources your application security to the user's email provider. It does not matter how long passwords you require and whatever clever password hashing you use. I will be able to get into your site by reading the email sent out to the user, given that I have access to the email account or am able to read the unencrypted email anywhere on its way to the user (think: evil sysadmins).
This might or might not be important depending on the security requirements of the site in question, but I, as a user of the site, would at least want to be able to disable such a password reset function since I consider it unsafe.
I found this white paper that discusses the topic.
The short version of how to do it in a secure way:
Require hard facts about the account
username.
email address.
10 digit account number or other information
like social security number.
Require that the user answers at least three predefined questions (predefined by you,
don't let the user create his own questions) that can not be trivial. Like "What's
your favorite vacation spot", not "What's your favorite color".
Optionally: Send a confirmation code to a predefined email address or cell number (SMS) that the user has to input.
Allow the user to input a new password.
I generally agree with you with some modification suggested below.
User registers at your site providing an email.
Verification email is sent to the users account with two links:
a) One link with the GUID to verify the registration b) One link with the GUID to reject the verification
When they visit the verification url from their email they are automatically verified and the verification guid is marked as such in your system.
When they visit the rejection url from their email they are automatically removed from the queue of possible verifications but more importantly you can tell the user that you are sorry for the email registration and give them further options such as removing their email from your system. This will stop any custom service type complaints about someone entering my email in your system...blah blah blah.
Yes, you should assume that when they click the verification link that they are verified. Making them click a second button in a page is a bit much and only needed for double opt in style registration where you plan to spam the person that registered. Standard registration/verification schemes don't usually require this.