I'm building a client which will interact with an existing bot built using the Microsoft Bot Framework. The bot works fine when I test with the existing channels. I can also successfully start a conversation when using the Direct Line API. However when I try to send a message to the bot using Direct Line API I get a 500 error with content "ServiceError".
I am sending an http Post request using Fiddler to https://directline.botframework.com/v3/directline/conversations/[MyConversationID]/activities with the following header:
Authorization: Bearer <My Secret>
Host: directline.botframework.com
Content-Length: 97
And Body
{
"type": "message",
"from": {
"id": "user1"
},
"text": "hello"
}
I am fairly certain the issue is not in my bot code as no breakpoint is hit. Has anyone had a similar issue? Or have any advice on how to go about debugging it?
Related
Google provides the HTTP message format for all the Oauth messages but nothing when it comes to the Calendar's API.
I suspect they want you to use one of their libraries -- but I don't use any of the languages associated with their libraries.
I'm using C++ and forming my own HTTP headers and message content.
Can anyone provide a standard HTTP format for Calendar-event-insert?
I know it must be in JSON construction.
The data I want to send is:
Calendar ID will be "primary"
Summary
Description
Start time
End Time
Based on oauth messages - I'm assuming the message may also have to contain:
ClientID
AccessToken
Scope
redirect_uri
I am looking for correct "Key" strings(case sensitive) and format.
Thanks in advance for any help.
You can do this all your self. The doucmentation is all there
Calendar event.insert
If all you want to do is see the HTTP request that is made by the api you can use If you use the event.Insert try me You can see the request it builds and test that its working
POST https://www.googleapis.com/calendar/v3/calendars/primary/events HTTP/1.1
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Accept: application/json
Content-Type: application/json
{
"end": {
"date": "2020-01-01"
},
"start": {
"date": "2020-01-01"
},
"description": "test",
"summary": "test"
}
With a post body of events.resource
oauth
If you have your own C++ oauth library you can probably use that to get an access token. Once you have the access token you simply need to add a Authorization header to the post request above with a bearer token of the access token.
Sorry i cant help much with the code for c++ but i made my own library for .net 3.5 because it was not supported by googles .net client library, so i can tell you that its doable you just have to do it all yourself.
Google c++ library
There is a c++ library its just deprecated but that doesn't mean you cant dig around in their code for a bit of help in doing this Google apis cpp client
Request URL:
https://content.googleapis.com/games/v1/players/[CORRECT_PLAYER_ID]?access_token=[CORRECT_APPLICATION_ACCESS_TOKEN]
The application is Server and set up like here:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
The only response is:
{
"error": {
"code": 500,
"message": null
}
}
In API Explorer I have:
...
"code": 401,
"message": "User has not completed registration."
...
What is wrong with my use case? How I can workaround Verification of Google Play Services User ID?
A 500 response is a server-side error, which sounds more like a bug than a question. It looks like they have a place to report bugs here.
I think this might not execute through the APIs Explorer this way because you haven't registered your project with the credentials being used; it doesn't currently have a way to use your own credentials instead.
We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.
We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.
In teams we can successfully create a card using the incoming webhook connector with this result.
This is created with the following JSON body from a POST action in Flow
{
"##type": "MessageCard",
"##context": "http://schema.org/extensions",
"summary": "This is the summary property",
"themeColor": "f46b42",
"sections": [
{
"startGroup": true,
"title": "**Pending Review**",
"activityTitle": "Ticket Title",
"activitySubtitle": "Requested by: ",
"facts": [
{ "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
{ "name": "Details:",
"value": "This ticket is ready for review." }
]
},
{
"potentialAction": [
{
"##type": "HttpPOST",
"name": "Approve",
"target": "ANOTHER-POST-URL-IS-HERE"
},
{
"##type": "HttpPOST",
"name": "Deny",
"target": "ANOTHER-POST-URL-IS-HERE"
}
]
}
]
}
We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.
When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.
After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation
It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.
So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?
Thanks!
Update:
Upon further testing we have determined that HttpPOST actions
work with just about any post url we can come up with except
Microsoft Flow Request URLs. They are exceptionally long urls so maybe
that has something to do with it?
Here's an example Flow request url.
https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ
When running teams in a web browser we are able to see the request
first posts to a api.teams.skype.com url and returns a generic
"ProviderError". Other non-flow urls also do the same but return
success.
This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.
The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.
However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).
This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.
Please let us know if that works.
BTW, the text you found is a documentation bug that has since been fixed:
Sorry for the confusion.
My bot based on the bot framework works pretty good. But when I first interact with the bot after a period of inactivity (let's say a day), then the bot seems to take very long time (about 10-45 seconds) to send back its first reply. After that reply the response time is pretty good again.
To me it seems the back-end service goes to some kind of sleep mode and the 1st request wakes it up.
Is there any way to influence this behavior? I concerned about the long initial response time for my users.
Thanks for your help.
If using Azure website, see "Always On Support"
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
I'm keeping the bot awake by periodically (every 15min) opening a conversation and sending a first message (activity) to the bot.
First, I start a conversation:
POST https://directline.botframework.com/v3/directline/conversations
Authorization: Bearer SECRET_OR_TOKEN
I got the SECRET_OR_TOKEN from the Azure resource: Azure Bot -> channels -> Web Chat -> e.g. Default Site -> Secret Keys
That's what a sample response from the docs looks like:
HTTP/1.1 201 Created
{
"conversationId": "abc123",
"token": "RCurR_XV9ZA.cwA.BKA.iaJrC8xpy8qbOF5xnR2vtCX7CZj0LdjAPGfiCpg4Fv0y8qbOF5xPGfiCpg4Fv0y8qqbOF5x8qbOF5xn",
"expires_in": 1800,
"streamUrl": "https://directline.botframework.com/v3/directline/conversations/abc123/stream?t=RCurR_XV9ZA.cwA..."
}
link to docs about creating a new conversation: https://learn.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-start-conversation?view=azure-bot-service-4.0#open-a-new-conversation
Then, I send a simple messsage (activity) as part of the conversation I just started:
POST https://directline.botframework.com/v3/directline/conversations/{conversation-id-received-from-create-conversation-request}/activities
Authorization: Bearer {token-received-from-create-conversation-request}
Content-Type: application/json
[other headers]
{
"locale": "en-EN",
"type": "message",
"from": {
"id": "user1"
},
"text": "hello"
}
You will have to replace the token and conversation Id in the request above. They are both returned in the start a conversation request.
here is a link to the docs about sending an activity to a conversation: https://learn.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-send-activity?view=azure-bot-service-4.0#send-an-activity
We're having an issue in generating access token using OAuth2 Service Account for Google Apps marketplace users. The token generated here would be used in accessing Google APIs(Contacts, Calendar, Mail, Admin SDK APIs) and thus all the Google Integrations within our Services are failing. This has started failing abruptly from March 9th 8AM PST. Can you please consider this as high priority and let us know the reason for the issue or if we have missed something here. We are getting API response as
{ "error": "invalid_request" }
Please find the below sample request with all the headers and params for 2 sample requests for "https://www.googleapis.com/oauth2/v4/token"(as in documentation) and "https://accounts.google.com/o/oauth2/token" endpoints. Both result in a error message with responses { "error": "internal_failure", "error_description": "Invalid Value"} and { "error": "invalid_request" } respectively.
P.S: The service email address,private key files used for generating the below signature in the sample requests works if we use respective Google Client libraries. But we are making use of Google's REST APIs. We've created a sample application in Google APIs console for testing with new service account details and this results in the same exception.
URL:
https://www.googleapis.com/oauth2/v4/token
Headers:
Content-Type:application/x-www-form-urlencoded
BODY:
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJodHRwczovL3d3dy5nb29nbGVhcGlzLmNvbS9vYXV0aDIvdjQvdG9rZW4iLCJzdWIi
OiJqYWdzQHNvbHV0aW9udGVzdC5jb20iLCJzY29wZSI6Imh0dHBzOi8vbWFpbC5nb29nbGUuY29t
LyIsImlzcyI6IjQ2OTU3MTY1OTAxNUBkZXZlbG9wZXIuZ3NlcnZpY2VhY2NvdW50LmNvbSIsImV4
cCI6MTQ1NzU5NTkwMCwiaWF0IjoxNDU3NTkyMzAwfQ==.VrsqS0nYSUVZn_SwMi7UJEYLDqRcWLzPrF9o6av-t1IYZbRkTybEdcnwWeUfnYXl_F88gFTllmRg
LSTBahM5gqpZrEAaWrRiDEVTo6rcN3hWm7MHcmZbwgdJB8B0ObV0Ivp5aTdLC5HcqsOumJvYpDCF
SyGU8StSg9pDujERzOo=
Response:
code:400
{
"error": "internal_failure",
"error_description": "Invalid Value"
}
URL:
https://accounts.google.com/o/oauth2/token
Headers:
Content-Type:application/x-www-form-urlencoded
BODY:
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJodHRwczovL3d3dy5nb29nbGVhcGlzLmNvbS9vYXV0aDIvdjQvdG9rZW4iLCJzdWIi
OiJqYWdzQHNvbHV0aW9udGVzdC5jb20iLCJzY29wZSI6Imh0dHBzOi8vbWFpbC5nb29nbGUuY29t
LyIsImlzcyI6IjQ2OTU3MTY1OTAxNUBkZXZlbG9wZXIuZ3NlcnZpY2VhY2NvdW50LmNvbSIsImV4
cCI6MTQ1NzU5NTkwMCwiaWF0IjoxNDU3NTkyMzAwfQ==.VrsqS0nYSUVZn_SwMi7UJEYLDqRcWLzPrF9o6av-t1IYZbRkTybEdcnwWeUfnYXl_F88gFTllmRg
LSTBahM5gqpZrEAaWrRiDEVTo6rcN3hWm7MHcmZbwgdJB8B0ObV0Ivp5aTdLC5HcqsOumJvYpDCF
SyGU8StSg9pDujERzOo=
Response:
code:400
{
"error": "invalid_request"
}
EDIT:Sample request as in the documentation. This code was working for us for the past 2 years and suddenly it stopped working yesterday.
POST /oauth2/v4/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI3NjEzMjY3OTgwNjktcjVtbGpsbG4xcmQ0bHJiaGc3NWVmZ2lncDM2bTc4ajVAZGV2ZWxvcGVyLmdzZXJ2aWNlYWNjb3VudC5jb20iLCJzY29wZSI6Imh0dHBzOi8vd3d3Lmdvb2dsZWFwaXMuY29tL2F1dGgvcHJlZGljdGlvbiIsImF1ZCI6Imh0dHBzOi8vYWNjb3VudHMuZ29vZ2xlLmNvbS9vL29hdXRoMi90b2tlbiIsImV4cCI6MTMyODU3MzM4MSwiaWF0IjoxMzI4NTY5NzgxfQ.ixOUGehweEVX_UKXv5BbbwVEdcz6AYS-6uQV6fGorGKrHf3LIJnyREw9evE-gs2bmMaQI5_UbabvI4k-mQE4kBqtmSpTzxYBL1TCd7Kv5nTZoUC1CmwmWCFqT9RE6D7XSgPUh_jF1qskLa2w0rxMSjwruNKbysgRNctZPln7cqQ
It worked after changing the sun.misc.BASE64Encoder encoding part in my code for generating jwt token.
byte[] encode = BASE64Encoder.encode(data).replaceAll("\n", "").getBytes();
(or)
Change your BASE64Encoder encoding part while generating jwt token from sun.misc.BASE64Encoder to org.apache.commons.codec.binary.Base64 as
Base64 encoder = new Base64();
byte[] encode = encoder.encodeBase64(data);
Add comments if you anyone need any clarifications.
This solution was provided by Google.