I want to figure out the format of telegram bot tokens to implement some validity checks, but there seems not official format description.
from my token and what I have found on the net, I can assume the following:
(up to) 46 characters length
starts with (up to) 10 digits followed by :
the remaining 35 characters are of class [[:alnum:]] plus - and _
can anyone (dis) confirm or point to documentation?
Let me summarize what we know so far:
to verify that a telegram API token has the correct format AND is currently valid you must make a Telegram getMe API call, e.g. on command line:
curl -s https://api.telegram.org/botYOURTOKEN/getMe
Nevertheless, we have some good guesses what a correct token must look like:
it consists of 8-10 digits followed by a :
the : is followed by a 35 character Telegram internal identifier/hash
the identifier is consisting of character class [[:alnum:]] plus _-, this fit's the characters documented for the deep linking parameter
Summary:
Token format: 8-10 digits:35 alnum characters plus _- , e.g. 123456789:AaZz0...AaZz9
Regex for testing: /^[0-9]{8,10}:[a-zA-Z0-9_-]{35}$/
If you want to check validity of a bot's token you can use the getMe method.
https://core.telegram.org/bots/api#getme
A simple method for testing your bot's auth token. Requires no
parameters. Returns basic information about the bot in form of a User
object.
Any non valid token will return 401 error.
I believe this would be a more robust approach than checking for correct formats.
The BOT token consists of two parts. In BOT_ID:BOT_ALPHANUMERIC_PART the BOT_ID is 8 to 10 digit long and the BOT_ALPHANUMERIC_PART has a length of 35 characters. So the total length is 43 to 45 characters.
If you want to validate a bot token then you can use: https://api.telegram.org/bot< YOUR_BOT_TOKEN>/getMe.
It will return the JSON data for your bot. It will throw a 401 error if the bot token is not valid.
Related
I'm trying to make an authorized Google API call using a JWT.
But when I send the request I get this error:
{
"error": "invalid_grant",
"error_description": "Invalid JWT Signature."
}
I'm following this manual https://developers.google.com/identity/protocols/oauth2/service-account#httprest
The JWT consists of three parts: header, claim set and signature. The header is always the same for authentication and I set every neccessary parameter in the claim set.
Now for the signature it says that you have to encode the header and claim set using Base64url and concatenate them together with a period: {Base64url encoded header}.{Base64url encoded claim set}
Then you sign this using SHA256withRSA and encode the result as well using Base64url again. After that you get the JWT also by concatenating them together: {Base64url encoded header}.{Base64url encoded claim set}.{Base64url encoded signature}
But when I send the request using the JWT I always get the said error. I also tried encoding it first and then signing it but I get the same result.
Am I creating the signature correctly?
If so does anyone have an idea what else the problem could be?
So with the information you provided, your signature is invalid.
You can use https://jwt.io debugger to validate your token and compare the Base64url results.
I am trying to run an SOQL query to the Salesforce REST API within a macro in Excel. I am using a LIKE statement to check if there are any email addresses with the same domain, which looks like this:
q=SELECT+email+FROM+Contact+WHERE+email+LIKE+'%#domain.com'
This is just the parameter given to the HTTP request, domain being a placeholder.
When I run the exact same request using Postman I get the correct response from the server, however in Excel I get Error 400 bad request.
When dropping the % it accepts the request, however then it obviously doesn't find any entries, as it is looking for the exact string "#domain.com".
Are there any known problems with the %-sign within vba? Or any other suggestions what could be the problem?
The problem is not with VBA, it is with your HTTP query. You need to escape the percent sign (%), which is a special characters. I guess Postman is doing this for you under the hood.
Hence, try :
q=SELECT+email+FROM+Contact+WHERE+email+LIKE+'%25#domain.com'
See : https://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_the_percent_character
If that's not enough for the query to succeed, you may as well escape the arobas sign (#):
q=SELECT+email+FROM+Contact+WHERE+email+LIKE+'%25%40domain.com'
I'm trying to use the Twitter v1.1 API endpoint:
POST : https://api.twitter.com/1.1/statuses/update.json?status=%2A
-or-
POST : https://api.twitter.com/1.1/statuses/update.json?status=*
After seeing some suggestions about URL Encoding (percent encoding) I'm trying to encode the asterisk (*) character using %2A
Other character encoding works, as expected. But the asterisk character results in the following error:
{ "errors": [{ "code": 32, "message": "Could not authenticate you." }]}
You can reproduce the error using the API Console Tool:
https://dev.twitter.com/rest/tools/console2
For Authentication I chose the Oauth 1 option.
It is possible to send a single * as a status update via the API - see https://twitter.com/edent/status/664713007268823040
I suspect that the library you're using isn't properly calculating the OAuth signature. It would help if you showed us the code you use and which library you're relying on.
Just replace the asterisk * with the wide-asterisk ＊. It is perfectly working for me
String tweet_text="Tweet text with asterisk *";
tweet_text= tweet_text.replaceAll("[*]","＊");
I've read conflicting and somewhat ambiguous replies to the question "How is a multipart HTTP request content length calculated?". Specifically I wonder:
What is the precise content range for which the "Content-length" header is calculated?
Are CRLF ("\r\n") octet sequences counted as one or two octets?
Can someone provide a clear example to answer these questions?
How you calculate Content-Length doesn't depend on the status code or media type of the payload; it's the number of bytes on the wire. So, compose your multipart response, count the bytes (and CRLF counts as two), and use that for Content-Length.
See: http://httpwg.org/specs/rfc7230.html#message.body.length
The following live example should hopefully answer the questions.
Perform multipart request with Google's OAuth 2.0 Playground
Google's OAuth 2.0 Playground web page is an excellent way to perform a multipart HTTP request against the Google Drive cloud. You don't have to understand anything about Google Drive to do this -- I'll do all the work for you. We're only interested in the HTTP request and response. Using the Playground, however, will allow you to experiment with multipart and answer other questions, should the need arise.
Create a test file for uploading
I created a local text file called "test-multipart.txt", saved somewhere on my file system. The file is 34 bytes large and looks like this:
We're testing multipart uploading!
Open Google's OAuth 2.0 Playground
We first open Google's OAuth 2.0 Playground in a browser, using the URL https://developers.google.com/oauthplayground/:
Fill in Step 1
Select the Drive API v2 and the "https://www.googleapis.com/auth/drive", and press "Authorize APIs":
Fill in Step 2
Click the "Exchange authorization code for tokens":
Fill in Step 3
Here we give all relevant multipart request information:
Set the HTTP Method to "POST"
There's no need to add any headers, Google's Playground will add everything needed (e.g., headers, boundary sequence, content length)
Request URI: "https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart"
Enter the request body: this is some meta-data JSON required by Google Drive to perform the multipart upload. I used the following:
{"title": "test-multipart.txt", "parents": [{"id":"0B09i2ZH5SsTHTjNtSS9QYUZqdTA"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]}
At the bottom of the "Request Body" screen, choose the test-multipart.txt file for uploading.
Press the "Send the request" button
The request and response
Google's OAuth 2.0 Playground miraculously inserts all required headers, computes the content length, generates a boundary sequence, inserts the boundary string wherever required, and shows us the server's response:
Analysis
The multipart HTTP request succeeded with a 200 status code, so the request and response are good ones we can depend upon. Google's Playground inserted everything we needed to perform the multipart HTTP upload. You can see the "Content-length" is set to 352. Let's look at each line after the blank line following the headers:
--===============0688100289==\r\n
Content-type: application/json\r\n
\r\n
{"title": "test-multipart.txt", "parents": [{"id":"0B09i2ZH5SsTHTjNtSS9QYUZqdTA"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]}\r\n
--===============0688100289==\r\n
Content-type: text/plain\r\n
\r\n
We're testing multipart uploading!\r\n
--===============0688100289==--
There are nine (9) lines, and I have manually added "\r\n" at the end of each of the first eight (8) lines (for readability reasons). Here are the number of octets (characters) in each line:
29 + '\r\n'
30 + '\r\n'
'\r\n'
167 + '\r\n'
29 + '\r\n'
24 + '\r\n'
'\r\n'
34 + '\r\n' (although '\r\n' is not part of the text file, Google inserts it)
31
The sum of the octets is 344, and considering each '\r\n' as a single one-octet sequence gives us the coveted content length of 344 + 8 = 352.
Summary
To summarize the findings:
The multipart request's "Content-length" is computed from the first byte of the boundary sequence following the header section's blank line, and continues until, and includes, the last hyphen of the final boundary sequence.
The '\r\n' sequences should be counted as one (1) octet, not two, regardless of the operating system you're running on.
If an http message has Content-Length header, then this header indicates exact number of bytes that follow after the HTTP headers. If anything decided to freely count \r\n as one byte then everything would fall apart: keep-alive http connections would stop working, as HTTP stack wouldn't be able to see where the next HTTP message starts and would try to parse random data as if it was an HTTP message.
\n\r are two bytes.
Moshe Rubin's answer is wrong. That implementation is bugged there.
I sent a curl request to upload a file, and used WireShark to specifically harvest the exact actual data sent by my network. A methodology that everybody should agree is more valid than on online application somewhere gave me a number.
--------------------------de798c65c334bc76\r\n
Content-Disposition: form-data; name="file"; filename="requireoptions.txt"\r\n
Content-Type: text/plain\r\n
\r\n
Pillow
pyusb
wxPython
ezdxf
opencv-python-headless
\r\n--------------------------de798c65c334bc76--\r\n
Curl, which everybody will agree likely implemented this correctly:
Content-Length: 250
> len("2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d646537393863363563333334626337360d0a436f6e74656e742d446973706f736974696f6e3a20666f726d2d646174613b206e616d653d2266696c65223b2066696c656e616d653d22726571756972656f7074696f6e732e747874220d0a436f6e74656e742d547970653a20746578742f706c61696e0d0a0d0a50696c6c6f770d0a70797573620d0a7778507974686f6e0d0a657a6478660d0a6f70656e63762d707974686f6e2d686561646c6573730d0a2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d646537393863363563333334626337362d2d0d0a")
500
(2x250 = 500, copied the hex stream out of WireShark.)
I took the actual binary there. The '2d' is --- which starts the boundary.
Please note, giving the wrong count to the server treating 0d0a as 1 rather than 2 octets (which is insane they are octets and cannot be compound), actively rejected the request as bad.
Also, this answers the second part of the question. The actual Content Length is everything here. From the first boundary to the last with the epilogue --\r\n, it's all the octets left in the wire.
I am newbie to jmeter. I am trying to test to login to my site say (example.com/session/new).
I have added the http cookie manager and 2 http request defaults.
In the first, am visiting example.com/session/new and extracting the authenticity token in the response data using regex meta content="(.+?)"name="csrf-token" . Now, in the second http request, I have a post request with the parameters as
name:utf value:(tickmark)
name :authenticity_token value: ${token}
name:email value:test#test.com
name:password value:test.
name:commit value:Sign In
And then am asserting for a text post login.
When I run the test, the assertion fails. as it results in 404.
In the request, I can see utf8=%E2%9C%93+&authenticity_token=%24%7Btoken%7D&email=test%40test.com&password=test&commit=Sign+In. Please help me fix this.
I know this is an old post, but I've been struggling with this exact same query, so I've decided to post my answer in case it helps anyone - it worked first time for me. So after requesting the login page for my site, the following csrf token is embedded in the html response;
<input type="hidden" name="csrfToken" value="fe5a48ebda7b98cbbf885b4a220ebe0c23b11125-1459096615520-1ac64aa945986cb1bd318d9c"/>
So when making the initial request for the login page, instead of using a Regular Expression Extractor, if the token is in the body of the HTML response, use an XPath Extractor instead.
If your response is not XML/XHTML compliant then tick the 'use tidy' checkbox.
For reference name add the reference you wish to refer to the token as e.g. token. When you add your parameters to the login request, you can then refer to your csrfToken as ${token}
Then for X-Path query use;
//input[#name="csrfToken"]/#value
The following tutorial shows you how to use a Regular Expression Extractor, but it should also help you to understand how to set up the query a bit more;
https://www.youtube.com/watch?v=SVxB3Tk4O4A&feature=iv&src_vid=hGkrSFKcj10&annotation_id=annotation_85358
Looks like you did every thing good , except correlation . After decoding your error url , I found that you correlation is not working . Below is the decoding URL "utf8=✓ &authenticity_token=${token}&email=test#test.com&password=test&commit=Sign In."
In your "Regular expression extractor" add below details
1. Reference Name:token
2. Regular Expression : name="csrfToken" value="(.+?)"
3. Template : $1$
4. Match No: 1
Note: Check the occurrences of "csrfToken", if you required first occurrence then enter 1 , if you required 2nd occurrence enter 2 ....etc.