I'm trying to enable some kind of "voice unlinking" (which should remove the access token from the google assistant) for my google action. I'm using the webhook fulfillment via Dialogflow and I'd like to send a response text like "Okay, your account linking got removed."
To do so, I'm currently trying to send a response using the status code 401, but it seems that my response body gets either ignored by the assistant or filtered along the way.
So my question is:
Is there a way to add any body information to a response with status code 401 or are there other ways to achieve the removing of access tokens via response?
Related
I am trying to access the api TemplateViews : createEdit using python docusign_esign api as below
api_client = ApiClient(header_name="Authorization", header_value=f"Bearer {access_token}",
host="https://demo.docusign.net/restapi/")
TemplatesApi(api_client).create_edit_view(account_id=account_id, template_id=template_id)
while accessing the create_edit_view I am getting the error as
"errorCode":"INVALID_REQUEST_BODY","message":"The request body is missing or improperly formatted."
when checked in the API explorer, I am able to get the response URL correctly. I found only the accountId and templateId is mandatory for accessing the api, am I missing something else here?
https://developers.docusign.com/docs/esign-rest-api/sdk-tools/python/reference/docusign_esign/apis/templates_api.html#docusign_esign.apis.templates_api.TemplatesApi.create_edit_view
You need to provide a return_url, it's a URL that your embedded sender will be redirected back to when they finished editing/creating the template.
This is a POST and this URL is provided in the body as JSON, not in the URL as a parameter.
https://developers.docusign.com/docs/esign-rest-api/reference/templates/templateviews/createedit/
My goal is consistent response data from JIRA.
Sometimes, the response will succeed with Basic Authentication. Other times I will get a 401 response saying to authenticate using OAuth. I get the 401 response on resources where I have permission.
OAuth doesn't make sense for my application.
The API docs say Basic Authentication is acceptable.
https://docs.atlassian.com/software/jira/docs/api/REST/8.5.13/
Note that this is not JIRA cloud.
Set winHTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
winHttp.Open "GET", targetURL, False 'false means blocking request
'targetURL = https://jira.{myOrg}.dev/rest/api/2/filter/{myFilterId}/columns
winHttp.setRequestHeader "Authorization", "Basic " + encodedCredentials
winHttp.send
debug.print winHttp.getAllRequestHeaders
debug.print winHttp.responseText
debug.print winHttp.Status
Edit: I get this HTTP Response Header
X-Seraph-LoginReason: AUTHENTICATED_FAILED
The meaning of this header is here: https://docs.atlassian.com/atlassian-seraph/2.6.1-m1/apidocs/com/atlassian/seraph/auth/LoginReason.html
It says I cannot be Authenticated. So JIRA doesn't recognize my credentials as being a correct pair.
It looks, like CAPTCHA was triggered, see https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/ (last paragraph)
A CAPTCHA is 'triggered' after several consecutive failed log in attempts, and requires the user to interpret a distorted picture of a word and type that word into a text field with each subsequent log in attempt. If CAPTCHA has been triggered, you cannot use Jira's REST API to authenticate with the Jira site.
You can check this in the error response from Jira. If there is an X-Seraph-LoginReason header with a value of AUTHENTICATION_DENIED, the application rejected the login without even checking the password. This is the most common indication that Jira's CAPTCHA feature has been triggered.
I'm building an API and there are some cases where our frontend can make a request to the API sending in data from a form. The data is checked on the backend and a response status code of 200, 201, or 400 could be returned.
For example,
status code 200 can mean that the request was good from the frontend to the API, but there is a suggestion from the validated data. (user submitted data, backend validated and has a suggestion for the user). We could also return 200 where everything checks out and the user confirms once more that the validated data is looking good.
status code 400 can mean that the request was bad but due to a missing field, an empty field, or there wasn't enough data in the request such that the backend couldnt validate the form data.
My current approach is to send a response back with a message, type, and the status code.
For example, from the above:
{"message": "The username should be: xxxx", "type": 0}, 200
{"message": "Everything looks good!", "type": 1}, 200
{"message": "Missing field", "type": 2}, 400
{"message": "Submitted data couldn't be validated. Try again?", "type": 3}, 400
Then on the frontend, I am able to look at the type property and status code to decide what message or how to display to the user.
Does this sound like a good approach or can this be improved? Please share any thoughts or recommendations for best practices.
Your backend should never send data that is suppose to guide the client on how to display a response or an error exception. The client alone is responsible for how messages, including error messages get displayed. The client UI can vary over time and even among devices.
If the user enters in some invalid data, you can perform the request and when you get back the response, you just display the error message in the appropriate location. Validation should be done on the client side and not allow the request to be sent when the input data is incorrect. Your backend can and should still validate the data being sent and return a 400 if it's incorrect, but the client app should just have a generic error handler for that. This really shouldn't happen though if you are validating on the client side.
I have been at this for sometime now and wanted to see if anyone had and idea of what I could be doing wrong. What I am trying to do is add a song to a playlist using the provided Spotify Web APIs. According to the documentation on this https://developer.spotify.com/documentation/web-api/reference/playlists/add-tracks-to-playlist/ I need to establish the scope of the user.
"adding tracks to the current user’s private playlist (including collaborative playlists) requires the playlist-modify-private scope" I have created the playlist as collaborative and I am using the login credentials of my personal account to reach this playlist I created. all this is under the same login.
What I am finding is that my scope is not getting added to my token on my call for my token causes a 403 error when I try to add the song.
Here is what that call looks like
https://accounts.spotify.com/authorize/?client_id=mynumber&response_type=code&scope=playlist-modify-private&redirect_uri=http:%2F%2Flocalhost:55141/Home/GetToken/
here are the docs on using authorization to get the correct token.
https://accounts.spotify.com/authorize/?client_id=894400c20b884591a05a8f2432cca4f0&response_type=code&scope=playlist-modify-private&redirect_uri=http:%2F%2Flocalhost:55141/Home/GetToken/
further more if I go into the dev support here
https://developer.spotify.com/documentation/web-api/reference/playlists/add-tracks-to-playlist/
and click the green try button and then request a new token it works.
Bottom line some how my request is not taking my scope request. Any Ideas?
Thanks
To get the token with a specific scope you need to go to the authorize endpoint and get the code. The code is what you want to get to be able http post to the endpoint https://accounts.spotify.com/api/token and get a token with your desired scopes. You can simply get the code by pasting a url like this in your browser...
https://accounts.spotify.com/authorize?client_id=<client_id>&response_type=code&scope=streaming%20user-read-email%20user-read-private&redirect_uri=<redirect_uri>
Only add %20 in between scopes if you have multiple ones
You will then be sent to spotify's website and they'll verify you want to do this. Once you verify it your browser will redirect you to what you set the redirect_uri to be in the url above. At the end of the url that you are sent to, you should be able to see the parameter name code with the code value assigned to it. You then get that code and put it in your http post body params to the https://accounts.spotify.com/api/token endpoint. Make sure you accurately follow the query params requirements in your post method.
An example of the post in python using the requests library:
authorization = requests.post(
"https://accounts.spotify.com/api/token",
auth=(client_id, client_secret),
data={
"grant_type": "authorization_code",
"code": <code>,
"redirect_uri": <redirect_uri>
},
)
authorization_JSON = authorization.json()
return authorization_JSON["access_token"]
In the end you should get a json that shows the scopes you set a long with a refresh the token later on to make more requests.
I know this answer is quite late but I was experiencing the same issue as well which is how I came across this question. I hope this helps anyone that sees this at a later date.
Source: https://developer.spotify.com/documentation/general/guides/authorization-guide/#client-credentials-flow
I noticed the Direct Line request url is like this: https://localhost:8011/api/ in the documention. What should replace it with?
I have deployed a todoBot example project from botbuilder Examples folder. And I have created a bot in My bots section, the ending point is: http://www.bigluntan.com:3978/api/messages. I have tested in Test connection to your bot section, it is working when I type something and send it. Right now, I want to give Direct Line a try. So I added Direct Line to Channels. But the most confused part is, how do I call this Direct Line api, cause the ending point is different than my bot's ending point.
The base URL is https://directline.botframework.com, so for instance, the POST request to get a new conversationId should be https://directline.botframework.com/api/conversations/
The request headers should include the Content-Type and also the following:
Authorization: BotConnector < Your secret >
where your secret is the code which was created when you created a Direct Line channel for your registered Bot (see image below). e.g.
Content-Type: application/json; charset=utf-8
Authorization: BotConnector pB7INWcXQjA.cwA.RF4.cglOUNHUOzWVv0Rlk3ovFNhtp1JPz1Zx9jmu8vX7zXs
Once you get a conversationId, you can POST a message using the URL https://directline.botframework.com/api/conversations/< conversationId >/messages
The body of the request should include the message text. You will not get the reply in the POST response. Instead, you need to get it by sending a GET to
https://directline.botframework.com/api/conversations/< conversationId >/messages. From there, you can get the "from" value in your first message, and use it in subsequent calls to the same conversation (otherwise the bot will not recognise the state, and just keep repeating the first reply message), e.g.
{
text: "yes",
from: "EQxvIzZOspA"
}
I found this out by trial and error. If you want to use the direct line api you should try https://directline.botframework.com
as the base URL