Hi I'd like to post to facebook via unification engine. I've already created a user, added and tested successfully a facebook connection, but when I post I get the following response:
{"Status":{"facebook":{"status":190,"info":"Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons.: "}},"URIs":[]}
When I use the facebook token, that was used for creating the connection, to post to facebook directly (without unificationengine), then it works just fine. What might be the problem here? Status 190 is neither documented on facebook nor on unificationengine.
#unificatinengine developers: it would be practical, if the errors returned by the service would be passed on inside the unificationengine response, this way debugging such errors would be easier, and the errors could also be processed programmatically.
Additional info
Today I seem not to be able to reproduce the response of yesterday. The postfields I use to post the message to facebook (the same as yesterday) are as follows:
{
"message":{
"receivers":[
{
"name":"me",
"address":"https://graph.facebook.com/v2.1/me/feed",
"Connector":"facebook"
}
],
"sender":{
"address":"sender address"
},
"subject":"test",
"parts":[
{
"id":"0",
"contentType":"text/plain",
"type":"body",
"size":25,
"data":"this is the plain message"
},
{
"id":"1",
"contentType":"text/html",
"type":"body",
"size":42,
"data":"<div>this is the <b>html</b> message</div>"
},
{
"id":"2",
"contentType":"text/plain",
"type":"link",
"size":17,
"data":"http://www.web.de"
},
{
"id":"3",
"contentType":"text/plain",
"type":"link_description",
"size":21,
"data":"some link description"
},
{
"id":"4",
"contentType":"text/plain",
"type":"link_title",
"size":10,
"data":"link title"
}
]
}
}
But today I get the following message back from unificationengine
{
"Status":{
"facebook":{
"status":100,
"info":"Unsupported post request. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api: "
}
},
"URIs":[]
}
Unfortunately this does not tell me, what unificationengine does internally for posting to facebook (which should not concern me), and what goes wrong there.
Does the "/v2/connection/info" show the details of the facebook connection that you have added? If not can you please update the connection with a new access token, using the same connection identifier for the "v2/connection/add" api endpoint, and check if it works.
unificationengine
Related
I've looked through every similar topic here in the forums, and couldn't really find anything that would help me.
I've built 3LO integration with my product, and trying to add webhooks via rest API. The first Hook is created successfully, how ever if I tried to create another hook for another user on the same App I get this message.
"webhookRegistrationResult": [
{
"errors": [
"Only a single URL per app is allowed to be registered via REST API. Currently used URL: https://example.com/api/webhooks/jira"
]
}
]
and my request is:
POST https://api.atlassian.com/ex/jira/{cloud-Id}/rest/api/3/webhook
{
"url": "https://example.com/api/webhooks/jira",
"webhooks": [
{
"jqlFilter": "status = Done or status != Done",
"events": [
"comment_created",
"comment_updated",
"jira:issue_created",
"jira:issue_updated"
]
}
]
}
I want to create a webhook for each user associated with my App to get any updates in issues or comments related to this user.
I am working on enabling Bixby Oauth2 Authorization on some actions.
I have configured the authorization.bxb as follows:
authorization {
user {
oauth2-authorization-code (PROVIDER) {
authorize-endpoint (https://X.com/authorize)
client-id (userId)
client-secret-key (password)
login-button-label(LOGIN)
token-endpoint (https://X.com/token)
}
}
}
I have declared my endpoint like:
action-endpoint (MyAuthenticatedAction) {
accepted-inputs ($vivContext)
local-endpoint (myAuthenticatedAction.js)
authorization {
user
}
}
Bixby successfully shows up popup to login and opens up X.com for authorization. After authorization a callback is done to Bixby with code and state parameters.
Bixby now sends the code received from the callback to token-endpoint. But even after getting a success response from the route (as per server logs), Bixby again shows the login popup.
The response of token-endpoint is:
{
"access_token":"XXXXXXXXXXXXXXXXXXX",
"expires_in": 3600,
"refresh_token": "XXXXXXXXXXXXXXXXXX"
}
Bixby continues to show the Login popup yet after receiving the response. Bixby debugger does not help as well.
Answering this question might require some more information about your capsule.
I'd recommend experiencing the behavior again and reaching out to the support team via the "Contact Support" option in Bixby Studio's Help dropdown menu.
This will give the Support team additional diagnostics to investigate further.
I've been trying to test a function app sending an activity to a bot that has an existing conversation, but to simplify for this post, I'll speak in terms of sending it via postman. I've have been butting up against an issue wherein the conversationId is not being found, despite confirming it does exist beforehand and I'm not entirely sure what I've done wrong.
I log onto portal azure, and go to my bot to Test in Web Chat. I authenticate the bot, and the conversation starts.
Here, I've checked the conversationId is exactly what I expect to be by examining the conversation calls response in Chromes debug tools, in this case it is 1GJ0N9UYKGyELu3LqpDF6b-a
Here is the exact conversation response...
conversationId: "1GJ0N9UYKGyELu3LqpDF6b-a"
expires_in: 3600
referenceGrammarId: "fcab5fbf-67c7-bf55-934a-274e525c78a9"
streamUrl: "wss://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/stream?watermark=-&t=ew0KICAi...."
token: "ew0KICA..."
So from here, in my mind I should be able to do the following in postman
POST https://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/activities
Content-Type: application/json
Authorization: Bearer {My webchats channels secret code}
Body:
{
"type": "message",
"from": {
"name": "foo"
},
"text": "bar"
}
I'd expect a 200OK and the message 'bar' to appear in my Test In Web Chat from 'foo', but it does not. Instead I get an error in postman stating:
{
"error": {
"code": "BadArgument",
"message": "Conversation not found"
}
}
How exactly can this be? If I've just created that conversation and can demonstrate that conversationId is in use, why is the post message saying it can't be found? Am I incorrectly using channels? Or doing something blindingly obvious here?
So to answer my own question, to make a long story short. It looks like the example activity supplied in the Microsoft documentation doesn't quite cut it. There is something else that is required, although I didn't have time to narrow it down.
The solution I took, as I was running low on time was to write a method to save an activity to cosmosDb as part of the authentication flow. This way I have an ironclad activity that I know has worked in at least the invoke stages of the dialog, and I know a conversation reference is correct and present. From there I pulled the activity and changed 4 fields in it.
activity.Type = "message",
activity.From = new From { Id = "{BotId}", Name = "Gilbert Bottfried", Role = "bot },
activity.Text = "{My message}",
activity.Subject = "{my message subject}"
From there, it was essentially a case of just creating a connector client and firing off this repurposed activity.
AppCredentials.TrustServiceUrl(serviceUrl, DateTime.MaxValue);
ConnectorClient client = new ConnectorClient(
new Uri(serviceUrl),
MicrosoftAppId,
MicrosoftAppPassword);
await client.Conversations.SendToConversationAsync(activity.Conversation.Id, activity);
It seems that this was enough to get it working, and it makes for a nice referenceable conversation Id for future messages. Although I found other issues with working with WebChat, because I suspect it's not entirely stable sending messages to and throw via websockets. The testing experience was much more stable on msteams itself, it seemed to handle my barrage of test messages like a champ.
This is essentially a bruteforce method, as I'm storing and sending a lot of unnecessary data, but it works. I may append this answer to trim down what I find to be necessary in the future, but that will require testing.
I'm authenticated with Instagram, and I got an access token with scope follower_list. Then I tried to get my followers list:
https://api.instagram.com/v1/users/self/followed-by?access_token=123.456
and all I got was an empty array, like following
{
"pagination": {},
"meta": {
"code": 200
},
"data": []
}
I don't really know if this is a problem from Instagram side or this is an expected behavior since I'm on Sandbox mode (although the documentation says I can expect to get real data even on Sandbox mode)
This is expected behavior.
In sandbox mode you will only get data from you and your sandbox users.
Add one of your followers to your sandbox, then only that user will be in API response. Once you go live, all users will be in API response.
I'm writing a simple SNS client that is meant to subscribe itself to an SNS topic and then listen for notifications. I can successfully submit a sns.subscribe request, but when I pick up the SubscriptionConfirmation POST message from AWS and try and respond using sns.confirmSubscription I get an AuthorizationError returned:
[AuthorizationError: User: arn:aws:iam::xxx:user/mv-user is not authorized to perform: SNS:ConfirmSubscription on resource: arn:aws:sns:us-east-1:xxx:*]
If I use exactly the same Token and TopicArn in a GET query to the server the subscription confirmation works fine, with no authentication.
Any ideas why it's not working? My SNS topic is wide open with publish/subscribe permissions set to 'Everyone'.
For reference, my code is something like this:
var params = {
TopicArn: topicArn, // e.g. arn:aws:sns:us-east-1:xxx:yyy
Token: token // long token extracted from POST body
};
sns.confirmSubscription(params, function (err, data) {
if (err) {
// BOOOM - keep getting here with AuthorizationError
} else {
// Yay. Worked, but never seem to get here :(
}
});
However, if I navigate to the URL similar to this in a browser (i.e. completely unauthenticated), it works perfectly:
http://sns.us-east-1.amazonaws.com/?Action=ConfirmSubscription&Token=<token>&TopicArn=arn%3Aaws%3Asns%3Aus-east-1%3Axxx%3Ayyy&Version=2010-03-31
The only differences seem to be the inclusion of 'Authorization' and 'Signature' headers in the programmatic version (checked using Wireshark).
Any ideas? Thanks in advance!
Update
In my code, if I just programatically do a simple GET request to the SubscribeURL in the SubscriptionConfirmation message this works fine. Just seems odd that the confirmSubscription API call doesn't work. Will probably stick to this workaround for now.
Update 2
Also get the same error when calling sns.unsubscribe although, again, calling the UnsubscribeURL in each notification works. Seems other people have run into that issue too but can't find any solutions.
I faced a similar issue while developing my application.
The way I ended up solving it is the following:
go to IAM and click on your user
go to the permissions tab and click on "Attach Policy"
use the filter to filter for "AmazonSNSFullAccess"
Attach the above policy to your user.
The above should take care of it.
If you wanna be fancy you can create a custom policy that is based on "AmazonSNSFullAccess" and apply it to you user instead.
The custom policy would be something similar to the following:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"sns:ConfirmSubscription"
],
"Effect": "Allow",
"Resource": "YOUR_RESOURCE_ARN_SHOULD_BE_HERE"
}
]
}
The error says it all:
[AuthorizationError: User: arn:aws:iam::xxx:user/mv-user is not authorized to perform: SNS:ConfirmSubscription on resource: arn:aws:sns:us-east-1:xxx:*]
is basically telling you that the IAM user you're using to call ConfirmSubscription doesn't have the proper permissions to do so. Best bet is to update the permissions for that IAM user, specifically adding ConfirmSubscription permissions.
(Based on your comments, even though the documentation says otherwise, the error is pretty specific... might be worth following up directly with AWS about this issue, since either the error message or documentation is incorrect).