Vkontakte API rejects requests with Captcha. Here is the example what I do.
After the third request I get:
Captcha error (14) - Captcha needed.
According to documentation it's sufficient to add captcha_sid and captcha_key parameters to the original requests and repeat the request.
But the response is still Captcha error (14). Is it possible to work with Captcha and OAuth in Vkontakte API?
Captcha error
Error code: 14
Error text: Captcha needed
and captcha confirmation is required, when:
action (e.g. sending a message) is performed too frequently, an API request may return "Captcha needed" error. After that a user needs to enter a code from the image and resend a request with a Captcha code input in the request parameters.
More information can be found in their manual.
If this error encounters, you need to process additionaly the following parameters from the response with the error message:
captcha_sid – captcha identifier;
captcha_img – a link to an image that will be shown to a user.
When user enters text from captcha_img you have to re-send the request adding following parameters:
captcha_sid – received ID;
captcha_key – text input you've gotten from user.
Do not forget to provide the valid access token as well, to make the user authorization, or the request would be declined with another type of error.
Related
I've successfully implemented Discord's OAuth2 flow using the authorization code grant type into my application. The end user navigates to Discord's OAuth2 link for my bot, authorizes its access, and Discord redirects them back to my site with a code querystring. The bot then exchanges this code for an access token by querying Discord's API. Documentation on this process is available here for reference.
However, roughly every 50-100 requests to the exchange endpoint, I receive a 403 with the error invalid_grant and the description Invalid "code" in request. Frankly, I don't understand how the code just provided by Discord's system is instantly invalid. The same user can complete the process again and no error is returned the second time.
Out of desperation, I tried toggling on the option in the Developers Dashboard named Requires OAuth2 Code Grant seeing that it said "if your application requires multiple scopes," but it made no effect. I've also tried endless debugging, but the circumstances under each occurrence are apparently random. Oddly enough, I can't find anyone with the same issue online.
Below is the request I'm making in Node.js using the superagent library. It matches the documentation and works perfectly, other than the response randomly being the error described.
superagent.post('https://discordapp.com/api/v6/oauth2/token')
.type('x-www-form-urlencoded')
.set('Content-Type', 'application/x-www-form-urlencoded')
.send({
client_id: process.env.BOT_ID,
client_secret: process.env.BOT_SECRET,
grant_type: 'authorization_code',
code,
redirect_uri: process.env.OAUTH2_REDIRECT_URI,
scope: 'identify guilds.join',
});
I can confirm that all variables match their expected values. The value of redirect_uri matches that of redirect_uri in the original URL used. code is the value of the code querystring returned through the OAuth2 flow.
What (if anything) am I doing wrong that's causing the error?
Update 1:
Discord has directed me to the API GitHub repo, and I found the issue closed here. Commented and will update here if I receive any helpful info or resolve the issue completely (hopefully the case).
Ran into the same issue using nodejs. Leaving here notes for prosperity:
On Node, if there is no explicit app.head() handler, the .post() handler receives all head requests
Several Android phones, upon being redirected from discord, first send a head request to the endpoint
Meaning:
The user authenticates on discord, then through the redirect back, does a head request. This pulls discord with the code, BUT directly afterwards it also does a post request, which will fail (as you already used the code once), and possibly un-authenticates the user.
Solution for my specific issue was an explicit .head handler for all callback endpoints, which basically just returned the same headers (a redirect) as the post one did, but without calling discord.
Hope this helps.
did you use the OAuth2 link to invite your bot to your server - with the correct permissions? If so, in your main.js file did you define the token?
I.e. bot.login(“YOUR_TOKEN_HERE”)
I would recommend not toggling the ‘Requires OAuth2 Code Grant’ as it is a pain to do anything with in the beginning.
Please let me know of any progress :)
Task is to receive messages and delete messages. Am modeling this in Postman. I can successfully execute the receive messages action, but not the delete message action.
I have tried copying the receipt handle string from the receive messages response and using it in the delete messages request, and also tried url encoding the string. Both returned errors
In Postman I run the aws sqs ReceiveMessage action and get the ReceiptHandle
<ReceiptHandle>AQEBjiliZegyBS/ZO9wta+a/heA/tSx/f6tLFqfH38jEZ2r9zguHAljXhG/B8tXaM+S6MKs/XGyZ206S3NC2V38CUKLO+sPF0mfP47wqu7+nAIwettlxTGQAYuCFqI1CYBYHXxgajB1UEiFz8Kc6v8SlWs/VPLX+IWjckoQOtMRl977sxM5pCLhMNvIwh1RYFvybM0D0WEbJEuYb9JU3DZuRZg/K5rjvNooPqER4FR1JJxpZiJ0tu6481CyePLtEh/J4+Yd2kYRyuqN788oEdSTZIKprA6lHUCiCmeuqCb0yEDsxJcCVX4GmDok5KMHm/E2bgjpRjVRxZ+mrnLqTSwojt0LXg61vv8dNF8QD4sngPXqhmKQ7yp5O6S8ygn4lIPaUGOl5cgX1HsB3Q9Pfv3sg4A==</ReceiptHandle>
Then I run the aws sqs DeleteMessage action
Try #1
Pass the ReceiptHandle with exact copy
Action=DeleteMessage&ReceiptHandle=AQEBjiliZegyBS/ZO9wta+a/heA/tSx/f6tLFqfH38jEZ2r9zguHAljXhG/B8tXaM+S6MKs/XGyZ206S3NC2V38CUKLO+sPF0mfP47wqu7+nAIwettlxTGQAYuCFqI1CYBYHXxgajB1UEiFz8Kc6v8SlWs/VPLX+IWjckoQOtMRl977sxM5pCLhMNvIwh1RYFvybM0D0WEbJEuYb9JU3DZuRZg/K5rjvNooPqER4FR1JJxpZiJ0tu6481CyePLtEh/J4+Yd2kYRyuqN788oEdSTZIKprA6lHUCiCmeuqCb0yEDsxJcCVX4GmDok5KMHm/E2bgjpRjVRxZ+mrnLqTSwojt0LXg61vv8dNF8QD4sngPXqhmKQ7yp5O6S8ygn4lIPaUGOl5cgX1HsB3Q9Pfv3sg4A==&Version=2012-11-05
In the response, Postman shows the ‘+’ being replaced with spaces, so assume this is an encoding problem:
The input receipt handle "AQEBjiliZegyBS/ZO9wta a/heA/tSx/f6tLFqfH38jEZ2r9zguHAljXhG/B8tXaM S6MKs/XGyZ206S3NC2V38CUKLO sPF0mfP47wqu7 nAIwettlxTGQAYuCFqI1CYBYHXxgajB1UEiFz8Kc6v8SlWs/VPLX IWjckoQOtMRl977sxM5pCLhMNvIwh1RYFvybM0D0WEbJEuYb9JU3DZuRZg/K5rjvNooPqER4FR1JJxpZiJ0tu6481CyePLtEh/J4 Yd2kYRyuqN788oEdSTZIKprA6lHUCiCmeuqCb0yEDsxJcCVX4GmDok5KMHm/E2bgjpRjVRxZ mrnLqTSwojt0LXg61vv8dNF8QD4sngPXqhmKQ7yp5O6S8ygn4lIPaUGOl5cgX1HsB3Q9Pfv3sg4A==" is not a valid receipt handle.
Try #2
URL Encode the Receipt Handle:
Action=DeleteMessage&ReceiptHandle=AQEBjiliZegyBS%2FZO9wta%2Ba%2FheA%2FtSx%2Ff6tLFqfH38jEZ2r9zguHAljXhG%2FB8tXaM%2BS6MKs%2FXGyZ206S3NC2V38CUKLO%2BsPF0mfP47wqu7%2BnAIwettlxTGQAYuCFqI1CYBYHXxgajB1UEiFz8Kc6v8SlWs%2FVPLX%2BIWjckoQOtMRl977sxM5pCLhMNvIwh1RYFvybM0D0WEbJEuYb9JU3DZuRZg%2FK5rjvNooPqER4FR1JJxpZiJ0tu6481CyePLtEh%2FJ4%2BYd2kYRyuqN788oEdSTZIKprA6lHUCiCmeuqCb0yEDsxJcCVX4GmDok5KMHm%2FE2bgjpRjVRxZ%2BmrnLqTSwojt0LXg61vv8dNF8QD4sngPXqhmKQ7yp5O6S8ygn4lIPaUGOl5cgX1HsB3Q9Pfv3sg4A%3D%3D&Version=2012-11-05
Error response is:
The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
Does the receipt handle need to be encoded?
Based on SQS DeleteMessage docs, your second attempt with URL encoding the receipt handle is correct.
It looks like you're having a problem with authentication & authorization - you need to sign your requests with auth params - this is what prevents (a) others from making unauthorized requests to your account's resources, and (b) others from intercepting and modifying (or replaying) your requests to your account's resources.
This tutorial provides great details on this how to do this auth via postman:
Postman makes it easy to setup all the necessary authorization using Collections. Configure the AWS authorization in the parent collection with the Access Key and Secret Access Key found in the AWS Console:
Then reference that authorization in each request:
For full information on how to construct the auth params more manually (which AWS API will do for you by the way), see http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html
Using cloud.invantive.com I am preauthenticating a connection to Exact Online using the OAuth2 Code Grant Flow. I have entered the client ID, the associated client secret and checked deviating redirect URI.
On clicking the Preauthenticate button, I get the following error without entering a username/password first:
Invalid authorization request
The URL on top is like:
https://start.exactonline.nl/api/oauth2/auth?response_type=code&client_id=4...stuff...b&redirect_uri=https%3A%2F%2Fcloud.invantive.com%2FUtilities%2FSettings&state=d...stuff...8
The error text does not give a clear hint, but in this case I had forgotten to replace the contents of the redirect URI by the value of the redirect URI given on the Exact Online app center on the app with the client ID used.
After correcting the redirect URI, I was presented with a login form. After entering credentials I got my refresh token.
I am seeing callback URL for DocuSign Oauth gets updated after I submit my email on DocuSign login page.
This is the URL for my OAuth flow which takes user to the DocuSign (sandbox) Login page.
https://account-d.docusign.com/oauth/auth?response_type=code&client_id=REST-41b3bb1d-94dc-44e3-b791-4810407b961d&scope=all&redirect_uri=https://localhost&state=https://localhost2/super/fx/oauth-callback.flex?osp=29cad06bee24300015fc6c67f95808d2%26intsys%3Dfe7a908b327570000b21578fac28005b#/username
Notice that the callback URL has a "osp" variable but it gets stripped away after email submission.
https://account-d.docusign.com/username?response_type=code&client_id=REST-41b3bb1d-94dc-44e3-b791-4810407b961d&scope=all&redirect_uri=https%3A%2F%2Flocalhost%2Fcb1&state=https%3A%2F%2Flocalhost2%2Fsuper%2Ffx%2Foauth-callback.flex%3Fosp#/password
Re:
I want to get some insight on why the 'osp' variable was stripped away in the URL in the process of OAuth flow and how we can prevent it. It seems to me that DocuSign encodes the URL once a user submits their email, would this issue be related to this encoding process?
In the OP, url being sent to DocuSign's OAuth service is:
https://account-d.docusign.com/oauth/auth?response_type=code&client_id=REST-41b3bb1d-94dc-44e3-b791-4810407b961d&scope=all&redirect_uri=https://localhost&state=https://localhost2/super/fx/oauth-callback.flex?osp=29cad06bee24300015fc6c67f95808d2%26intsys%3Dfe7a908b327570000b21578fac28005b#/username
Let's pull it apart:
response_type=code
client_id=REST-41b3bb1d-94dc-44e3-b791-4810407b961d
scope=all
redirect_uri=https://localhost
state=https://localhost2/super/fx/oauth-callback.flex?osp=29cad06bee24300015fc6c67f95808d2%26intsys%3Dfe7a908b327570000b21578fac28005b#/username
So it is not the case that the osp value is being included with the redirect uri. It is being included with the state query parameter.
You should instead send
response_type=code&client_id=REST-41b3bb1d-94dc-44e3-b791-4810407b961d&scope=all&redirect_uri=https://localhost?osp=29cad06bee24300015fc6c67f95808d2%26intsys%3Dfe7a908b327570000b21578fac28005b#/username&state=1234567890
In addition, it is not clear to me that including two ? characters in the overall URL is supported. I'd try encoding your ?, which is the second one in the URL.
I'm working on an application that integrates with GitHub and am having issues "logging out" a user that was previously authenticated. When I attempt to revoke the authorization token for the user, I get a 404 Not Found response from the API.
According to the documentation, it looks like I should just be able to make a DELETE request to https://api.github.com/authorizations/[authTokenId]. I have tried a couple of different things including:
Ensuring the Authorization header is set with the current auth token
Ensuring the UserAgent header is set with what I use for the rest of the API calls
Nothing seems to result in anything but a 404 though. I have validated that the token is valid and has that the Id matches with what is expected (id property from the authorization response and from the "check an authorization" response as well). Anyone have another thought on something I could be missing?
Looks like currently you need to include a basic authentication header (including a base64 encoded string of your username/password).
Not ideal for my purposes since I want to revoke the token when a user "logs out" of my application and I don't want to store their username/password. I've sent GitHub support an email about it to see if they have any other ideas.
Update 6/12/2013
GitHub support has stated that the above is expected at this juncture, but they are considering updating to allow revoking an authorization using the authorization as the means of authentication.
For now I'm going to require the user to enter their username/password a second time to revoke the authorization.