Resource URL
GET https://<MATD_IP>/php/session.php
The following HTTP headers should be specified in the session request:
Accept: application/vnd.ve.v1.0+json
Content-Type: application/json
VE-SDK-API: Base64 encoded "user name:password" string
VE-API-Version (Optional)
I am confused onto what does it mean by specifying base64 encoded string. I have tried to do it but I am failing at it. Can anybody help me with the exact header parameters by giving an example.
Thank you
You could use this in your Pre-request Script:
let base64 = Buffer.from("username:password").toString('base64')
pm.request.headers.add({key: "VE-SDK-API", value: base64})
This will convert to Base64 and then create the header with the encoded value.
It most likely means that you need to provide a base64 string for that field. Write down the credentials with a : in between. Ex:
cooluser:str0ngP4ssword
Then you encode this exact string as base64 which would give you:
Y29vbHVzZXI6c3RyMG5nUEBzc3dvcmQ=
You can encode via terminal (Linux) echo "XXX" | base64 or just search for "base64 encode" on the WEB (not really recommended due to security reasons).
You can then use it for the headers:
Accept: application/vnd.ve.v1.0+json
Content-Type: application/json
VE-SDK-API: Y29vbHVzZXI6c3RyMG5nUEBzc3dvcmQ=
VE-API-Version 1.x
Omit echoing trailing new line using option -n (for not needed):
echo -n "username:password" | base64
Related
I am attempting to filter unwanted incoming emails in my cPanel environment (with Exim as Mail Transfer Agent) based on the message body contents.
Often the message body is base64 or quoted-printable encoded (Content-Transfer-Encoding: quoted-printable or Content-Transfer-Encoding: base64), and in such cases
"$message_body contains <string>"
"$message_body matches <regexp>"
conditions fail because (I think) no decoding of the encoded message body takes place.
I read in The Exim Specification that for headers Exim decodes base64 or quoted-printable header text (an extract below):
$header_<header name>: or $h_<header name>:
$bheader_<header name>: or $bh_<header name>:
. bheader removes leading and trailing white space, and then decodes base64 or quoted-printable
MIME “words” within the header text, but does no character set translation.
. header tries to translate the string as decoded by bheader to a standard character set.
Can Exim decode base64 or quoted-printable encoded message body too? Can that be done in a cPanel & WHM environment?
The weirdest thing, two of my javascript files have stopped being served due to incorrect mime type from apache. All my JS files have text/javascript, but two of them get application/octet-stream.
When troubleshooting I noticed that when I connect to the web server, it outputs "31c2" before the content of the file (see image). This is not an invisible character in the actual file, verified by hexdump. I am assuming that this is the source of the incorrect mime type reporting, but where does this come from? I noticed that after the file is output, apache also adds "0" on a single line.
How do I figure out what causes this? I might add that this file was last edited in 2017 and has worked flawlessly until today or yesterday, and I can't understand why.
Here are two requests side by side to a working .js file (left) and the one that reports incorrect mime type (right). There is no .htaccess file in any parent directory either.
Those things such as 31c2 that you see are hex encoded numbers. Now, if we decode 31c2, we get 12738. These strings only appear when you are using HTTP/1.1. Not when you are using HTTP/0.9, HTTP/1.0, HTTP/2.0, etc.
Why do these 'HEX' encoded numbers appear?
This occurs because HTTP/1.1 uses chunked transfer-encoding. Hence, you can see the header: Transfer-Encoding: chunked.
Chunked transfer-encoding has these hex strings:
CRLF a CRLF
Keep in mind that: CR = \r (carriage return), LF = \n (new line).
Now, for example, if you want to send Hello, World! to the user:
HTTP/1.1 200 OK
[CRLF]
Connection: Keep-Alive
[CRLF]
Transfer-Encoding: chunked
[CRLF]
[CRLF] # END OF HEADERS: the first hex won't contain another CRLF, idk why they chose to do this
5 # 5 in hex, is 5
[CRLF]
Hello
[CRLF] # first CRLF of hex
8 # 8 in hex, is 8
[CRLF] # second CRLF of hex
, World!
[CRLF] # first CRLF of hex encoding
0 # means this is the end of the transfer
[CRLF] # second CRLF of hex encoding
[CRLF] # contains third CRLF for the end too
HTTP/1.1 uses chunked transfer-encoding to send chunks as they are ready to be sent. Instead of sending all the data at once. This is especially useful for huge file transfers, where, with chunked transfer, the server doesn't need to calculate the size of the response in advance, saves time (this is also what causes the total-download size to be sometimes invisible when you are downloading stuff from some websites).
Why is your JS file not being detected as JavaScript?
It may be a bug in Apache. You should probably add this to your .htaccess/apache2.conf/httpd.conf to solve this issue:
AddType text/javascript js
I try to get the response of my call in a String but the result look like if the charset defined is not good.
val apiResponse = URL("https://api.stackexchange.com/2.2/questions?order=desc&sort=activity&site=stackoverflow")
.readText(Charset.forName("ISO-8859-1"))
println(apiResponse)
I try using "UTF-8" but the result is the same, full of badly encoded characters.
Why ?
The server returns the web page compressed with gzip, so it naturally includes lots of undisplayable characters.
You can confirm this without using Kotlin, e.g.:
$ wget 'https://api.stackexchange.com/2.2/questions?order=desc&sort=activity&site=stackoverflow'
[output snipped]
$ file 'questions\?order=desc\&sort=activity\&site=stackoverflow'
questions?order=desc&sort=activity&site=stackoverflow: gzip compressed data, from TOPS/20, original size 19820
You can use Kotlin to uncompress it — but this is easier if you read the URL as bytes, to avoid any character-set conversions:
val url = URL("https://api.stackexchange.com/2.2/questions?order=desc&sort=activity&site=stackoverflow")
val content = GZIPInputStream(ByteArrayInputStream(url.readBytes()))
.bufferedReader()
.use { it.readText() }
I implemented push notification message for one of my application. I am getting notification in general but when i want to send actual data that is below 2k byte but getting below response with error...
request:
curl --header "Authorization: key=AIzaSyDx43ertyuOm459WczpBwAqKSw8IxFHGQs" --header Content-Type:"application/json" --header "Encryption: salt=wtKCDREj4rt562LWk1muo3FA==" --header "Crypto-Key: dh=BPqg7luAvMisfd45sj5ZaBX7GSz9sSfSt3lhpA3Ea3qHCE_l6pi4bXZ3AsNX179iGWMDDQT9IqhHyXBw0230_kc=" --header "Content-Encoding: aes56ggcm" https://android.googleapis.com/gcm/send -d "#/tmp/data" --insecure
/tmp/data having very less data.
Response:
{"multicast_id":6999436345666218533,"success":0,"failure":1,"canonical_ids":0,"results":[{"error":"MessageTooBig"}]}
I looked at some articles and found below...
Check that the total size of the payload data included in a message
does not exceed GCM limits: 4096 bytes for most messages, or 2048
bytes in the case of messages to topics or notification messages on
iOS. This includes both the keys and the values.
but my complete payload data size is less that 2k bytes.
Any help would be appreciated.
Message Too Big
The total size of the payload data that is included in a message can't exceed 4096 bytes. Note that this includes both the size of the keys as well as the values.
Happens when error code is MessageTooBig.
According to Raghav Sood:
You can use the following to get the bytes of a String:
String s = "some text here";
byte[] b = s.getBytes("UTF-8");
int bytes = b.length;
Make sure that you specify the encoding of the String, as different encodings may take up a different number of bytes for the same String. In the above example, UTF-8 is used as the encoding.
To convert the bytes into kB, just divide by 1024.
This will help you ensure that your message is and will not exceed against the total size of payload data.
I was having a similar problem "MessageTooBig" when it obviously wasn't while sending WebPush notifications via GCM.
It turned out that the problem was in Base64 encoding. As per web push encryption spec, for salt and public key url safe base64 encoding needs to be used, but for GCM raw_data you need to just "regular" Base64 encoding (with == at the end).
Changing base64 encoding for raw_data fixed this problem for me.
I am trying to upload an image to the Twitter-API, which requires a multipart/form-data oAuth-signed POST request.
However there seems to be some kind of mistake in my code, as I'm getting 503 Errors everytime I try to call the function. Which should be a "Temporarily unavailable" error, but it is constant over different times of the day and apparently other people had the same problem with uploading media via the Twitter-API.
Following some examples I found, I am currently building the multipart header like this:
postData := '--', boundary, String crlf,
'Content-Disposition: form-data; filename="upload.png"; name="media"', String crlf,
'Content-Type: image/png', String crlf,
'Content-Transfer-Encoding: base64', String crlf,
morphAsBinaryString, String crlf,
'--', boundary,'--', String crlf.
The actual httpPost command goes like this:
request := client httpPost: url
content: postData
type: 'multipart/form-data; boundary=', boundary
do:[:req | WebUtils oAuthSign: req url: url extra: extra using: personalOauthParams].
Is this the correct approach?
Thanks in advance for any help.
UPDATE:
As it turns out there was a String crlf missing in the line before the media data. Now I am getting an "Authentication Required" error. Other API-calls work without problem.