Wrong recipient error while using SignIn after switching Dialogflow agents - node.js

I made a new Dialogflow agent and transferred my code, which was working on the previous agent, to the new one. One of the main things my agent does is account linking using the SignIn helper. I also got a new clientID in my Google Assistant console and pasted it in my code.
Now however I get this error in my NGROK: {"error":"Wrong recipient, payload audience != requiredAudience"}
I assume the problem is related to Dialogflow's clientID, which I replaced in my code after transferring to a new agent. The problem? I have no idea what the error means and the internet isn't helping me understand it too much, since I'm not advanced at this yet.
This is how I link my clientID as described here: https://developers.google.com/assistant/identity/google-sign-in
const app = dialogflow({
clientId: 'xxxxxxxxxxxxxx.apps.googleusercontent.com',
debug: false,
});
Does anyone know what the problem might be/have experience with this error? I know it isn't in my code, since it worked before.

Related

passport-apple inexplainable invalid_client on nodejs backend -- using clean example repository with fresh set of credentials

I've cloned https://github.com/ananay/passport-apple-example and replaced the config with this:
clientID: "com.myname.web",
teamID: "myteamid",
callbackURL: "https://myurldev.com/auth/apple/redirect",
keyID: "mykeyid",
privateKeyLocation: path.join(__dirname, "../apple-key.p8")
I've also added SSL certificate on my machine and starting the server with https, all works fine & is recognized by my browser. I'm also starting the app on port 443 and proxying using my hosts file myurl.dev.com -> 127.0.0.1.
I have the same auth setup for facebook, google & microsoft and everything works fine.
I have:
Created a new APP identifier and enabled Sign in with Apple for it, named it: com.myname.dev
Created a new SERVICE identifier and enabled Sign in with apple, called it: com.myname.web
Added "https://myurldev.com/auth/apple/redirect" to the "Reply URLS" on the service identifier com.myname.web
Set my app identifier com.myname.dev as the main app identifier my service to be grouped with.
Created a private key and enabled sign in with apple, interface confirmed the presence of grouped ID com.myname.web bundled with com.myname.dev for which the key was created.
I have confirmed using console.log that the private key is indeed at the path being passed as parameter.
converted the .p8 file to base64 & then back to UTF-8 in an attempt to use the string for privateKeyString
successfully implemented Apple Oauth several times in the past using passport-apple
This time around, for some reason, auth simply doesn't work.
If I set the clientID as the APP identifier, not the service, I'm getting
invalid_request
Invalid web redirect url.
instead of invalid_client
Any advice on debugging this is highly appreciated. Thank you.
EDIT #1:
I have dug a bit deeper into the passport-apple package to figure out if anything goes against apple's docs around token generation, but the flow never reaches that part, indicating things go wrong on the actual configuration in Apple's console & what I'm trying to use for my project.
EDIT #2
2 of the app Ids I have created always throw "wrong redirect uri" because they're not service IDs so I can't configure redirect_uri, this will change if to "required" if I pass undefined as a redirect_uri.
One of the app ids throws only invalid client_id instead, regardless if I pass undefined or good value for redirect_uri.
EDIT #3
Went full vanilla through the OAuth code flow process and just created a url & redirected the user it, failing with this method is consistent with what is happening when using the passport-apple module.
const url = new URL("https://appleid.apple.com/auth/authorize");
url.searchParams.append("state", "fdbd287b1f");
url.searchParams.append("response_type", "code");
url.searchParams.append("scope", "name email");
url.searchParams.append("response_mode", "form_post");
url.searchParams.append(
"redirect_uri",
"https://raiseitupdev.com/auth/apple/redirect",
);
url.searchParams.append("client_id", "com.myname.web");
return res.redirect(url.toString());
[Creator of the library here.]
Did it stop working in development too? I feel this is a configuration error because the actual thing is working live on my website:
https://passport-apple.ananay.dev
Please follow up on this Github issue. Thanks!
https://github.com/ananay/passport-apple/issues/23

How to replace default response in account linking on Google Assistant

As part of an action configured for account linking with the following topology:
Actions-on-Google->Dialogflow->Webhook,
I'm seeing Google Assistant injecting its own message prior to going through the account linking flow, as follows:
"I need to link your <action-name> to Google. Is that ok?"
The linking flow is triggered by the following in the webhook:
public ActionResponse launchRequestHandler(ActionRequest request) throws Exception {
ResponseBuilder responseBuilder = getResponseBuilder(request);
responseBuilder.add(new SignIn());
}
I'd like to be able to replace the above stock message with a custom one, however when attaching a context to a sign in card with our own message, like so:
String speech = "Hi, I see that your account isn't connected. "
+ "I've sent a link to your Google Assistant app that will get you started and set up in just several simple steps. "
+ "Don't worry, I'll be here waiting, just call me when you're ready.";
responseBuilder.add(
new SignIn()
.setContext(speech));
I'm still seeing the default message tacked at the end:
"Hi, I see that your account isn't connected.
I've sent a link to your Google Assistant app that will get you started and set up in just several simple steps.
Don't worry, I'll be here waiting, just call me when you're ready.,
I need to link your <action-name> to Google. Is that ok? "
How can I replace the Google default message with my own?
To ensure a consistent experience for users, you cannot replace the default message. You can only set the context, which lets you provide your custom information for the user ahead of the generic question.
The context is an additional piece of information which may be more relevant to your Action. Let's say it's connecting to your example.com account. You would add the context as a string:
app.intent('Login', conv => {
conv.ask(new SignIn('To provide you with personalized info from example.com'))
})
The user would hear this message, with the generic prompt appended:
To provide you with personalized info from example.com, I need to link your Example Action to Google. Is that ok?
Then you can say yes or no, and go through the OAuth flow / Google Sign-In flow.

Dialogflow account linking - google home

I'm having slight issues using dialogflow and the SignIn helper with google home, in the simulator it works all fine with account linking including the google home simulator, but when I reset and attempt to link it again with my physical google home that I have, it's saying the following phrase everytime I hit the sign in intent:
"Alright, no problem. Just so you know, that means you won't be able to use your account with x. If you change your mind, you can always come back and sign in then. Sorry, can you say that again?"
This phrase seems to come from when you decline to sign in.
Does anyone have any idea how to fix this? It should actually refer me to my application, on the Google Home simulator is directs me to something like this which is correct:
"To get your account details, you'll need an account with x. To get you signed in, I'll just need some info. If you want more details, say "Tell me more. " So, can I ask Google for your name, email address, and profile picture?"
Heres my intent code:
import { dialogflow, SignIn} from 'actions-on-google';
import '#babel/polyfill';
const app = dialogflow({
debug: true,
clientId: process.env.client_id,
});
app.intent('StartSignIn', conv => {
conv.ask(new SignIn('Sign in'))
});
exports.main = app
P.S does anyone know how to get the sign in status, I can't seem to get it via (conv, params, signin) handler of the intent.
Many thanks!
I replicated your scenario and found a similar issue. Google Assistant went unresponsive after initiating the sign-in intent from my phone. The simulator worked fine for phone and speaker devices. I think it might not be available yet. You can give it a try with a deployed version.
Regarding the (conv, params, signin), be sure to add the actions_intent_SIGN_IN to the intent you want to be detected when the sign-in flow finishes.
After that, you can access the status, like this:
app.intent('signInConfirm', (conv, params, signin) => {
conv.close(`Sign in status: ${signin.status}`);
});

Is accessing the Customer Profile API possible using the Cloud9 code editor in the AWS Lambda web console? If so, how?

First off, I'm new to Alexa skill development, so I have much to learn. I've been banging my head off the desk trying to figure this out. I've found various tutorials and have gone over the information provided by Amazon for accessing the Customer Profile API via an Alexa skill but still can't manage to obtain the customer's phone number.
I'm using the AWS console in-line code editor (Cloud9). Most, if not all, instructions use something like 'axios', 'request', or 'https' modules which I don't think is possible unless you use the ask-cli (please correct me if I'm wrong). Also, I followed a tutorial to initially create the skill which had me use Skillinator.io to create an AWS Lambda template based on the skill's JSON in the Amazon Developer console. The format of the code in the Customer Profile API tutorials does not match what was provided by the Skillinator.io tool. The way the Intent handlers are set up is different, which is where I believe my confusion is coming from. Here's an example:
Skillinator.io code:
const handlers = {
'LaunchRequest': function () {
welcomeOutput = 'Welcome to the Alexa Skills Kit!';
welcomeReprompt = 'You can say, Hello!';
this.emit(':ask', welcomeOutput, welcomeReprompt);
},
};
Tutorial code:
const LaunchRequestHandler = {
canHandle(handlerInput) {
return handlerInput.requestEnvelope.request.type === 'LaunchRequest';
},
handle(handlerInput) {
const speechText = 'Welcome to the Alexa Skills Kit!';
return handlerInput.responseBuilder
.speak(speechText)
.reprompt(speechText)
.withSimpleCard('Hello World', speechText)
.getResponse();
}
};
Can anyone shed some light and help me understand why there is a difference in the way the handlers are formatted, and how (if possible) to create the request to the Customer Profile API?
I've already completed the steps for the necessary permissions/account linking.
Thanks in advance.
EDIT:
I've learned that the difference in syntax is due to the different versions of the sdk, Skillinator being 'alexa-sdk' or v1 and the various tutorials using 'ask-sdk' or v2.
I'm still curious as to whether using modules like 'axios' or 'request' is possible via the in-line code editor in AWS console or if it's even possible to access the Customer Profile API using sdk v1?
I've decided to answer the question with what I've learned in hopes that others won't waste as much time as I have trying to understand it.
Basically, it is possible to use the above-mentioned modules in sdk v1 using the AWS console's in-line code editor but you must create a .zip file of your code and any necessary modules and upload that .zip to Lambda.
I've edited my original answer to include my findings for the difference in syntax in the intent handlers.
From what I can tell (and please correct me if I'm wrong), it is not possible to access the Customer Profile API using the sdk v1.

MS botbuilder Skype calling bot example

After installing this nodejs calling bot example
bot works and after Skype user calls it plays default menu, but after that when user say one of the options nothing happens, it just play menu again after a while.
Find more details here
Anyone managed to activate next step of waterfall?
After lot of twist and turns and some strange implications on my own code, where I used segments from example I mentioned in my question, it turns out that the problem I experienced was related with token and nbf time (defines the time before which the jwt must not be accepted) stopping my workflow. I managed to overcome the problem by using clockTolerance option in CallConnector.js file. So, instead of doing this (140 line):
decoded = jwt.verify(token, secret);
just add options part:
decoded = jwt.verify(token, secret, jwtVerifyOptions);
where jwtVerifyOptions could be specified like this:
const jwtVerifyOptions = {
ignoreExpiration: false,
ignoreNotBefore: false,
clockTolerance: 300
};
I have reproduced this issue.it's related to a change to our state service.
you can add below line before begin with bot.dialog
bot.set('storage', new builder.MemoryBotStorage());

Resources