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());
Related
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.
I'm integrating SustainSys.Saml2, with Gluu server as my IdP. I'm using the scaffolded Identity pages out of the box. When I run in localhost, and I view the console log everything seems to work with the SAML communication, and I even see a couple lines that read:
Sustainsys.Saml2.AspNetCore2.Saml2Handler[0]
Successfully processed SAML response Microsoft.IdentityModel.Tokens.Saml2.Saml2Id and authenticated
Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationHandler[10]
AuthenticationScheme: Identity.External signed in.
Unless I'm mistaken, that indicates everything's good on the SAML end of things. But what I don't then understand is why, in ExternalLogin.OnGetCallbackAsync, the command
var info = await _signInManager.GetExternalLoginInfoAsync();
finds info set to null.
For the record, in Startup.cs, I have:
services.AddAuthentication()
.AddSaml2(options =>
{
options.SPOptions.EntityId = new EntityId("{entityId}");
options.IdentityProviders.Add(
new IdentityProvider(new EntityId("{entityId}"), options.SPOptions)
{
Metadatalocation = "{metadataURL}",
});
options.Validate();
});
I was able to figure this out based on this GitHub issue, and Anders' notes in there.
I'll link to my comment there. Read Anders' comment above that for explanation. https://github.com/Sustainsys/Saml2/issues/1030#issuecomment-616842796
I recently opened a new Instagram account and registered a new client. The information I received back from Instagram included the client_id and the client_secret.
I will only run the script on my machine, and be the sole user of the project, so I don't need any user to "log in". But for some reason, whenever I try to make any calls to the Instagram-Node API, it returns the following error:
{ [Error: OAuthAccessTokenException: The access_token provided is invalid.]
code: 400,
error_type: 'OAuthAccessTokenException',
error_message: 'The access_token provided is invalid.',
retry: [Function] }
That's weird to me, because I have an identical setup with an older Instagram account and different credentials, that seem to be working just fine. Then again, that was before November, when Instagram changed some of their API policies.
I use the Instagram-Node like so:
ig.use({
client_id: "dxxxxxxxxxxxxxxxxxxxxxxx2",
client_secret: "4b0xaxaxaxaxaxaxaxaxaxaxa53c03100e4"
});
and make my first call like this:
ig.user_media_recent(user.toString(), options,...
I tried handling the authentication by rerouting my request through the redirect_uri as shown in the Instagram-Node documentation, but even then, all of my requests are unsigned, so it's not clear to me what I would do with the access_token any way.
Any help would be much appreciated!
Okay, the problem is a misunderstanding of the limits of the Sandbox Mode, they essentially make it impossible to look up media from users who are not in your sandbox.
The documentation here says:
The first point is important and it means that the API behaves as if
the only users on Instagram were your sandbox users, and the only
media ever posted were the last 20 for each of these users.
I was trying to find media from users who are not in my sandbox, and so I received an error. The reason that my previous credentials weren't affected is because they are still grandfathered into the grace period, June 2016, at which time they will expire as well. Thanks!
I ran into this same issue. If your app is using oauth, you will cause Instagram to spaz out if you pass the client_secret and client_id stuff again. I had to take these out of my code. So I just pass the access_token now.
ig.use({ access_token: token });
ig.user_media_recent(config.userid, { count: 20 }, function(err, medias, pagination, remaining, limit) {
Were my equivalant statements.
EDIT: I forget to mention. This is after a cycle of these for those confused:
api.authorize_user
api.get_authorization_url
When I activate the OWIN logout-everywhere feature via security stamps and use the OnValidateIdentity-Callback of the CookieAuthenticationProvider with the SecurityStampValidator-class, the user is logged out every time he closes the browser.
provider.OnValidateIdentity =
SecurityStampValidator.OnValidateIdentity<MyUserManager, MyUser>(
System.TimeSpan.FromSeconds(10),(manager, user) => {
return user.GenerateUserIdentityAsync(manager);
});
However, when I do the plumbing myself (lookup and comparison of the security stamps, rejecting or renewing the identity) in the OnValidateIdentity-callback, everything seems to work fine.
Is this a known bug, or do I miss here something? Or is there a good documentation about the CookieAuthenticationProvider and the use of OnValidateIdentity?
Digging with google only shows me some simple samples, but gives no further insight.
Additional information
I use an own implementation of the UserStorage which saves all the
data in a database
I noted that every page request calls two times the
GetSecurityStampAsync of the UserStorage, wheras when I use my
implementation, only one call is done.
Installed Identity Version is 2.0.1
This is basically a bug, the regeneration of the cookie should respect the current Remember Me option on the cookie. As a workaround, you can copy the OnValidateIdentity code and feed in the current context properties to flow the Persistent mode through:
context.OwinContext.Authentication.SignIn(context.Properties, identity);
This is resolved in ASP.NET Identity 2.2. See https://aspnetidentity.codeplex.com/workitem/2319
I have found the following code in the disassembly of SecurityStampValidator.OnValidateIdentity:
// .. some other code
// ...
ClaimsIdentity claimsIdentity = await regenerateIdentityCallback(userManager, tUser);
if (claimsIdentity != null){
context.get_OwinContext().get_Authentication().SignIn(new ClaimsIdentity[]
{
claimsIdentity
});
}
It seems to me, that the SignIn-operation is incomplete and should set the remember-me option? Therefore I assume that the implementation of SecurityStampValidator is buggy.
I am using the Spring Security Core plugin and can successfully log users in and out of my application. However, when the user successfully signs up, I don't understand how to set that user's security context on the signup postback so that they can be redirected to a secure page without having to log in again. Any help is welcome. Thanks.
The other link you reference is 2 years old. Since then I've added a reauthenticate method to SpringSecurityService. See section "6.2 SpringSecurityService" in the docs:
http://grails-plugins.github.com/grails-spring-security-core/docs/
I eventually came upon this link, which does the trick: https://stackoverflow.com/a/7112838/469106
Here are the contents of that link:
If you don't have the password, you can load the user via
def user = User.findByUsername(username)
and setting the authority array in the 3-parameter constructor. Create the auths via
GrantedAuthority[] auths = user.authorities.collect { new GrantedAuthorityImpl(it.authority) }
Then you can omit the call to authenticate() and use:
SecurityContextHolder.context.authentication = new UsernamePasswordAuthenticationToken(username, 'unknown', auths)