I'm working with Watson Virtual Agent (WVA) and a custom conversation workspace (WCS) and was hoping that there was a way that I could go from a custom conversation flow back into a WVA flow.
My specific use case would be when I want to escalate to agent from within WCS. There are already preconfigured flows for this inside WVA which I think calling on would be the easiest way to complete the escalate to agent process.
I know that to force WCS to return to the WVA I need to somehow add
system.dialog_stack[0] == root
to the context, however, the instructions here don't go further than saying add to context. So far I just get errors when I add it to context with and without "" marks. Whilst I don't think that this would solve my issue I have actually been unable to test this.
I would welcome any answers specific to my example, specific to how to actually implement system.dialog_stack[0] == root in WCS or to the general question which I expect will have more uses for other users.
Having done some more research I have discovered that it is possible to call on the specific Escalate to Agent flow type using an action.
The use of actions is explained in the documentation I linked to above although there is no list of preconfigured actions.
Here is an example of a node in WCS that would allow one to connect to agent using the connection that you've set up in WVA:
{
"output": {
"text": "I will connect you with an agent now.",
"action": {
"name": "agent"
}
}
}
Until there is a list of the actions available for use in WVA/WCS I don't know if this is a fix that would work with other flows. I found this using Postman extension in Chrome and using my WVA keys and replicated the action that was called during the Escalate to Agent flows in WVA.
Related
First, thanks Hasura for incredible good product! I love it.
I have issue with derive action with Hasura Console. My use case:
I enable anonymous role for subscribe function (everybody can send email to subscribe)
I have configured permission on my subscribe table, everything is fine.
I want to validate the user input on server side, for example, validate email format. I have followed by this guide about derive action. I found no mistake here.
But I got the error "Type query_root must define one or more fields." when I hit "Derive action" at the first time.
According to this question, as I understand, I need to have object type for root query.
Of course, I will have object type for root query eventually. I can work around by giving some dummy queries for anonymous role. But I do not like that cheat anyway.
Any idea on that? Any help will be highly appreciated.
Edited:
My related current version:
Hasura 1.3.2
One click deployment using Docker on Digital Ocean.
In IAM I tried creating the following policy for a user (account id in arn obfuscated):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-west-2:999999999999:table/busUsers"
}
]
}
However, it resulted in:
This policy defines some actions, resources, or conditions that do not provide permissions. To grant access, policies must have an action that has an applicable resource or condition. For details, choose Show remaining Learn more
Show remaining shows:
One or more actions do not have an applicable resource.
I looked up the Learn more link and it says to replace the arn in the Resource element with *. I am confused now. What does * mean? I want to grant access to a specific DynamoDB table of mine. How do I specify that?
EDIT: I removed all DyanamoDB actions and just selected one GetItem and it's:
When I deselect GetItem, both error messages go away.
When I select table Any, the first error message goes away.
When I select Resource Any, the second error message goes away.
Its because you are granting permissions for all dynamodb actions to a table resource, but not all of those actions are actually applicable to a table.
For example dynamodb:DescribeStream is not applicable to a table, only to a Stream, but your are granting permission to this resource anyway.
You can safely ignore this warning.
EDIT: You may not have realised you can just click Save Policy and it will work fine.
EDIT: Thanks for posting your screenshot. There are no errors here, just warnings, which might be better called tips in this case.
When you enter the ARN of a resource manually, AWS does not appear to recognise what type of resource it is (i.e. a table). If you add the resource through the table ARN generator, you wont any warnings. In either case you end up with the same policy.
It is possible that you are running into a bug [discussed by Amazon employee rob#AWS] of the IAM Policy Visual editor itself (and therefore not experiencing any actual problem):
https://forums.aws.amazon.com/thread.jspa?threadID=282453
When I alleviated my personal problem (which had me looking at this Question in the first place), my similar warnings still persisted (even after my problem was solved by something else) - that leads me to believe my similar experience per the Visual editor may have indeed been that bug (and not causing/involved in my prior problem at all).
I'd like to determine if a user is currently "online" or connected to the Meteor server.
I need this information before I send the user message, If the user is not connected I'd like to send the message via email.
I know that for traditional web applications that are totally state-less the definition of "online" use is a bit not clear but since modern web frameworks rely on websocket, a user is supposed to be online if a websocket is open.
The question is does Meteor include a method to determine if a user is connected or not?
Summarized: yes, there is such a mechanism.
There are for example package, that store the active login connections of the users with the meteor server and make them available either via an own collection or as part of the user profile.
See: https://github.com/dburles/meteor-presence
(Creates a new collection, called Presences)
or https://github.com/dan335/meteor-user-presence/
(Creates a user's profile entry, called presence. However, has also a collection to store and update the information in the background)
or https://github.com/mizzao/meteor-user-status
(Thanks to blueren in the comments)
Code example (from the first listed package)
Meteor.onConnection(function(connection) {
// console.log('connectionId: ' + connection.id);
Presences.insert({ _id: connection.id });
connections[connection.id] = {};
tick(connection.id);
connection.onClose(function() {
// console.log('connection closed: ' + connection.id);
expire(connection.id);
});
});
If you don't want to rely on the packages you may make use of that mechanism yourself.
See: https://docs.meteor.com/api/connections.html#Meteor-onConnection
I have a scenario that I want to use the Agent and USM component to implement the customer command to control a computer, but I donot want to install an application or a service,
how can i reach this goal?
thank you very much!
Steve
You can install an empty service, one that does not actually run anything. This is often called a 'recipe about nothing'. It should look something like this:
service {
name "empty"
type "WEB_SERVER"
lifecycle {
locator {
NO_PROCESS_LOCATORS
}
}
}
Add your custom commands here and you can run them from the Cloudify CLI/REST API as usual.
Note the use of the NO_PROCESS_LOCATORS directive - this tells the USM not to perform any process liveness scans.
Is there any way to write a security rule or is there any other approach that would make possible only for currently connected (not authenticated) user to write/read certain location - admin should also be able to write/read?
Can a rule be written that disallows users to read of complete list of entries and let them read only entry that matches some identifier that was passed from client?
I'm trying to exchange some data between user and Node.js application through Firebase and that data shouldn't be able to read or write by anyone else other than user and/or admin.
I know that one solution would be that user requests auth token on my server and uses it to authenticate on Firebase and that would make it possible to write rule which prevents reads and writes. However, I'm trying to avoid user connecting to my server so this solution is not first option.
This is in a way session based scenario which is not available in Firebase but I have
some ideas that could solve this kind of problem - if implemented before session management:
maybe letting admin write into /.info/ location which is observed by client for every change and can be read only by active connection - if I understood correctly how .info works
maybe creating .temp location for that purpose
maybe letting admin and connected client could have more access to connection information which would contain some connection unique id, that can be used to create location with that name and use it inside rule to prevent reading and listing to other users
Thanks
This seems like a classic XY problem (i.e. trying to solve the attempted solution instead of the actual problem).
If I understand your constraints correctly, the underlying issue is that you do not wish to have direct connections to your server. This is currently the model we're using with Firebase and I can think of two simple patterns to accomplish this.
1) Store the data in an non-guessable path
Create a UUID or GID or, assuming we're not talking bank level security here, just a plain Firebase ID ( firebaseRef.push().name() ). Then have the server and client communicate via this path.
This avoids the need for security rules since the URLs are unguessable, or close enough to it, in the case of the Firebase ID, for normal uses.
Client example:
var fb = new Firebase(MY_INSTANCE_URL+'/connect');
var uniquePath = fb.push();
var myId = uniquePath.name();
// send a message to the server
uniquePath.push('hello world');
From the server, simply monitor connect, each one that connects is a new client:
var fb = new Firebase(MY_INSTANCE_URL+'/connect');
fb.on('child_added', newClientConnected);
function newClientConnected(snapshot) {
snapshot.ref().on('child_added', function(ss) {
// when the client sends me a message, log it and then return "goodbye"
console.log('new message', ss.val());
ss.ref().set('goodbye');
});
};
In your security rules:
{
"rules": {
// read/write are false by default
"connect": {
// contents cannot be listed, no way to find out ids other than guessing
"$client": {
".read": true,
".write": true
}
}
}
}
2) Use Firebase authentication
Instead of expending so much effort to avoid authentication, just use a third party service, like Firebase's built-in auth, or Singly (which supports Firebase). This is the best of both worlds, and the model I use for most cases.
Your client can authenticate directly with one of these services, never touching your server, and then authenticate to Firebase with the token, allowing security rules to take effect.