I need to send non-encoded data from web browser.
In Postman, I can send ' or 1=1-- without encode it.
But when I enter the string in the form using a web browser, It will be automatically encoded into %27+or+1%3D1--. I don't know how to send ' or 1=1-- from a web browser because the string's decoded value is the same. How to make the browser send the string as ' or 1=1-- instead of %27+or+1%3D1--?
Related
Currently we are using SendGrid Inbound Parse to receive emails.
We handle the Inbound Parse webhook request by Azure HttpTrigger function implmented in C# (.NET 6).
When the received email is in UTF-8 encoding, everything's okay.
However, when we tried to receive email in shift_jis encoding, headers are okay,
but japanese characters in text and html are garbled.
From Inbound Parse request, we got the charsets as below:
subject: UTF-8
to: UTF-8
from: UTF-8
cc: UTF-8
html: shift_jis
text: shift_jis
And the string we got directly from request.form["text"] (or "html") was already garbled like "�e�L�X�gshiftJis-007"
(should be "テキストshiftJis-007"), so we cannot use string in request directly.
Then we tried to convert (System.Text.Encoding.Convert method) it from charset encoding (shift_jis) to utf-8,
and the result was different from original string but still unreadable "?e?L?X?gshiftJis-007".
Our questions are:
When using C# HttpTrigger Azure function to handle Inbound Parse webhook request
(request data is passed through AspNetCore.)
What encoding is in html/text string in Inbound Parse webhook request
when the email is send in encoding other than UTF-8?
How to read text and html in shift_jis encoding (or other encodings excluding UTF-8)
correctlyfrom an Inbound Parse webhook request?
Twilio Developer Evangelist here. I would recommend reaching out to the support team because it requires to investigate the payload to figure out what is going on.
I also tried to replicate the issue on my end with using send_raw option. Here's the payload, and it does contain shift_jis characters. You may be able to process the payload manually.
(stripped X-Mailer info)
'Content-Type: text/plain; charset="shift_jis"\n' +
'X-Mailer: \n' +
'Content-Transfer-Encoding: quoted-printable\n' +
'\n' +
'\n' +
'=83e=83L=83X=83gshiftJis-007\n'
I’m trying to get Dropbox token from call-back parameters but the parameters are always empty.
Here is my code:
sURL :=
https://www.dropbox.com/oauth2/authorize' +
'?response_type=token' +
'&client_id=' + MyAppID +
'&redirect_uri=http://127.0.0.1:8888/';
ShellExecute(0, 'OPEN', PChar(sURL), '', '', SW_SHOWNORMAL);
Next I have IdHTTPServer set to listen http://127.0.0.1:8888/ address.
On executing the browser with Dropbox log-in popup. When I made log-in the redirection is made and the “IdHTTPServerCommandGet” events is called. So far so good.
In the browser I can see the next URL:
http://127.0.0.1:8888/#access_token=123&token_type=bearer&uid=1234&account_id=dbid%1234
But in “IdHTTPServerCommandGet” events the parameters are always empty:
ARequestInfo.UnparsedParams; // Empty
ARequestInfo. QueryParams; // Empty
if ARequestInfo.Params.Count > 0 then // Empty
sToken := ARequestInfo.Params[0];
And here is my question. How can I get the whole URL with parameters from IdHTTPServer?
Look very closely at the redirect url you are seeing in your browser. All of the parameters you want to access are after a # character, not a ? character. That puts them in the "fragment" portion of the url rather than the "query" portion. A web browser does not include a url's "fragment" in an HTTP request to a web server. That is why the TIdHTTPRequestInfo properties are empty - the parameters are literally not being sent to your TIdHTTPServer. The redirected url needs to put the parameters in the url's "query" instead. That is Dropbox's responsibility to handle correctly on its end.
That being said, you don't actually need the TIdHTTPServer at all, if you use an embedded web browser directly in your app, such as Delphi's TWebBrowser. You can hook into the embedded browser to catch the redirect directly, and all of the data that is in the redirected url. This also allows you to use a custom url scheme for the redirect url, you don't have to use "http(s):" (see Redirect URLs for Native Apps).
I am trying to follow the guide to generate Oauth authentication tokens for YAHOO DSP API.
Base64 encoding is a way of encoding binary data into text so that it can be easily transmitted across a network without error.
In this step, you will take the client ID and client secret that the YDN console generated for you and encode them using the base64 protocol. You can use an online encoding service like base64encode.org.
No matter which service you use, ensure that no spaces are appended to the CLIENT_ID and CLIENT_SECRET keys and separate the CLIENT_ID and CLIENT_SECRET with a colon, i.e. CLIENT_ID:CLIENT_SECRET.
The generated value will now be referenced as ENCODED(CLIENT_ID:CLIENT_SECRET) in this guide.
An example is given:
CLIENT_ID = dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
CLIENT_SECRET= a7e13ea3740b933496d88755ff341bfb824805a6
AUTHORIZATION = ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Using the recommended website I get the wrong AUTHORIZATION.
I have tried both encoding the whole thing at once ie. encode(CLIENT_ID:CLIENT_SECRET), and each element individually encode(CLIENT_ID):encode(CLIENT_SECRET).
Attempt encoding whole thing:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCTOiBhN2UxM2VhMzc0MGI5MzM0OTZkODg3NTVmZjM0MWJmYjgyNDgwNWE2
Attempt encoding each element:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5B4oCT:YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
Expected result:
ZGoweUptazlOMnBJYXpsc1prMWlUekl4Sm1ROVdWZHJPV1ZFVW1wVk1GcFdUWHBSYldOSGJ6bE5RUzB0Sm5NOVkyOXVjM1Z0WlhKelpXTnlaWFFtZUQwME5BLS06YTdlMTNlYTM3NDBiOTMzNDk2ZDg4NzU1ZmYzNDFiZmI4MjQ4MDVhNg==
The difference between 'each element' and the expected result is only a few characters corresponding to the end of client_ID and the colon.
B4oCT: should be BLS06.
Links to full documentation:
https://developer.yahoo.com/dsp/api/docs/authentication/tokens.html
https://developer.yahoo.com/dsp/api/docs/traffic/info/sandbox.html
Update:
The final character of Client_ID is '–' . This is some sort of non-standard character that is interpreted as two dashes i.e.'--' in utf-8 and windows 1258.
One different, TO NOTE is, that when you decrypt the expected output you will get your client id as
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA--
instead of
dj0yJmk9N2pIazlsZk1iTzIxJmQ9WVdrOWVEUmpVMFpWTXpRbWNHbzlNQS0tJnM9Y29uc3VtZXJzZWNyZXQmeD00NA–
NOTE, there are two "-" at the end.
OAuth client auth token is always generated using Base64 encoding with following format
Base64_Encoding(CLIENT_ID:CLIENT_SECRET)
Most of the usage perform this Base64 encoding with encoding type as "UTF-8".
It looks like, Yahoo requires this token with different encoding. On "https://www.base64encode.org/" if you try to encode your "CLIENT_ID:CLIENT_SECRET" with "Windows-1254" as destination charset, you will receive the expected result. So, it looks like both encoding and decoding here is done keeping "Windows-1254" charset in place.
My app sends out an email with a URL in it. The url contains a query string attribute that is encrypted. I CGI escaped the encrypted value so that symbols like + * . etc are escaped. The escaped URL appears in the email as expected, but when we click on the link, the encrypted values are decrypted.
For Example, the url in the email is as follows
http://development.com/activate/snJAmJxkMo3WZ1sG27Aq?album_id=2&email=5M%2BjE1G6UB26tw/Ah%2Bzr1%2BJSSxeAoP6j&owner_id=4
email=5M%2BjE1G6UB26tw/Ah%2Bzr1%2BJSSxeAoP6j
when we click on this link the url in the browser appears as
http://development.com/activate/snJAmJxkMo3WZ1sG27Aq?album_id=2&email=5M+jE1G6UB26tw/Ah+zr1+JSSxeAoP6j&owner_id=4
email=5M+jE1G6UB26tw/Ah+zr1+JSSxeAoP6j
The + is substituted with space. As a result
params[:email] = 5M jE1G6UB26tw/Ah zr1 JSSxeAoP6j
which gives me a 404.
Is there any way I can avoid this situation. How can I make the url in the browser also appear as
http://development.com/activate/snJAmJxkMo3WZ1sG27Aq?album_id=2&email=5M%2BjE1G6UB26tw/Ah%2Bzr1%2BJSSxeAoP6j&owner_id=4
in the browser?
In order to avoid this situation I Hex encoded the email attribute so that the it contains only alphabets and numbers. Used these are the methods to Hex encode and decode.
convert string2hex:
def hexdigest_to_string(string)
string.unpack('U'*string.length).collect {|x| x.to_s 16}.join
end
convert hex2string
def hexdigest_to_digest(hex)
hex.unpack('a2'*(hex.size/2)).collect {|i| i.hex.chr }.join
end
Is there a length limit for the fragment part of an URL (also known as the hash)?
The hash is client side only, so the rules for HTTP may not apply to it.
It depends on the browser.
I found that in safari, chrome, and Firefox, an URL with a long hash is legal, but if it is a param send to the server, the browser will display an 414 or 413 error.
for example:
an URL like http://www.stackoverflow.com/?abc#{hash value with 100 thousand characters} will be ok. and you can use location.hash to get the hash value in javascript but an URL like http://www.stackoverflow.com/?abc&{query with 100 thousand characters} will be illegal, if you paste this link in the address bar, a 413 error code will be given and the message is the client issued a request that was too long. If that is a link in a web page, in my computer, Nginx response the 414 error message.
I don't know the situation in IE.
So I think, the limitation of the length of URL is just for transmission or HTTP server, the browser will check it sometimes, but not every time, and it will always be allowed to be used as a hash.
There is definitely a length for the whole url.
Read
RFC2616 - Hypertext Transfer Protocol
Maximum URL length is 2,083 characters in Internet Explorer