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.
Related
I am trying to view data in a Redis database.
It is compressed data using Lettuce 6.1.1 version compression library.
It uses a GZIP compression type.
I have tried several online tools to convert the GZIP text to a readable ASCII format.
The tools fail because it does not recognize the GZIP text as GZIP data. Maybe it has something to do with the compression algorithm lettuce uses to compress the data.
Can anyone point me to a tool where I can decompress this data to readable ascii text?
Here is an example of the compressed data:
\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x00\xABVN-\xCBLNu,JM\xF4+\xCDMJ-R\xB2R2604\xB44Q\xAA\x05\x00\x190\x9B\xD1\x1E\x00\x00\x00
This should translate to a number: 301194
Here is a second example:
1.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB04\x01\x00\x93\xC0t\xC3\x06\x00\x00\x00
2.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB0\xB0\x04\x00o\x8D\xDE\xA4\x06\x00\x00\x00
3.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB04\x07\x00)\x91}Z\x06\x00\x00\x00
4.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB04\x03\x00\xBF\xA1z-\x06\x00\x00\x00
5.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB04\x00\x00\x8A\x04\x19\xC4\x06\x00\x00\x00
6.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003602\xB04\x02\x00\xA6e\x17*\x06\x00\x00\x00
7.\x1F\x8B\x08\x00\x00\x00\x00\x00\x00\x003604\xB44\x01\x00J\x05\x03\xD0\x06\x00\x00\x00
This should be a list of 7 service area numbers.
Not sure of the order but the values should be:
302090
302092
302097
302094
302096
302089
301194
I tried using this online tool:
https://codebeautify.org/gzip-decompress-online
There is no translation that appears in the translation window and no error is shown.
I also tried a this website:
https://www.multiutil.com/gzip-to-text-decompress/
I get the error: Invalid compression text
UPDATE
The RedisInsight screenshot below shows the key-value information. The value information that is compressed as gzip I would like to translate.
I wanted to copy the value that I have highlighted and decompress it so I can document what is stored in the database.
There is nothing wrong with your examples 1 through 7. They are all valid gzip streams that decompress to:
302094
302089
302097
302096
302090
302092
301194
Your first example in your question however has an error in the integtity check at the end. It decodes to:
{#eviceAreaNumber":"301194"}
While the deflate compressed data in the gzip stream is valid, the CRC that follows it is not. The uncompressed length after that is incorrect as well.
The online tools you point to are expecting Base64 encoded data. Not the partial hex encodings you are trying there.
I store a byte array with 5 bytes in a Redis entry. Writing and reading using a client library works and expected, but when I try to read the value in a Redis console I get something I don't know how to interpret:
>get keyHere
"\x02\x8e\x8b\x0cb"
There is something I clearly don't understand because \x0cb is not a hex value for a byte and there are only 4 \x (and I expected 5 for 5 bytes).
Confused, I decided to performed an experiment. I educated myself about how to set raw bytes; I set an entry's value to "\x01\x07" and read it back. I expected "\x01\x07" but the read value is shown as "\x01\a".
>set "3" "\x01\x07"
OK
>get 3
"\x01\a"
How should I read entries in a Redis cache in the Redis console to see raw bytes?
If the byte is not printable, redis-cli prints the hex format, otherwise, it prints the c-escpaped sequence.
because \x0cb is not a hex value for a byte and there are only 4 \x (and I expected 5 for 5 bytes)
The first 4 bytes are not printable, so they are printed as hex format. The last byte is the b, which is printable.
I expected "\x01\x07" but the read value is shown as "\x01\a".
\x07's c-escaped sequence is \a, and is printable.
How should I read entries in a Redis cache in the Redis console to see raw bytes?
If you need the raw bytes (which might not be printable), you can specify the --raw option when running redis-cli.
I am using the TRX library to process the ISO8583 Message. I am receiving a Raw data EOF character. But the last byte is not removed from the buffer as it's not defined in the packager and it's causing an issue in parsing the next transaction. How to manage this?
And while sending a response back how to add EOF character?
Normally, this kind of stuff (protocol characters) is removed before decoding ISO8583 data.
For example, you read 100 bytes from the socket. And it's ISO data + EOF character. You would remove EOF character and process 99 bytes of ISO data through a decoder.
And reverse is true when you send data. You encode your data first then add EOF character. The resulting byte array goes into the socket.
Sorry, I don't know anything about TRX library, but, hopefully, general advice helps you somewhat.
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
With reference to this question and to ASIO libary, I would like to know what is the maximum size of ICMP v6 reply packet. I'm using ASIO library to listen for and receive ICMPv6 packets, but I don't know what size of buffer to use in order to prevent buffer over flow. I'm confused by IPv6 supporting extension headers.
Ex code:
asio::streambuf replyBuffer;
replyBuffer.consume(replyBuffer.size());
size_t length = icmpV6Socket->receive(replyBuffer.prepare(65536) );
One of the great features of Boost.Asio's buffers is that they provide protection against buffer overruns. Boost.Asio's buffers pair together a handle to the actual memory and the size. Thus, as long as the size is properly set or deduced, then Boost.Asio operations will not produce buffer overruns.
Nevertheless, the details for ICMPv6 sizes are as follows. IPv6 Header is 40 bytes, and reserves 2 bytes to represent the Payload Length. Thus, the max payload for IPv6, including extension headers, is 65,535. This differs from IPv4, where the Total Length included the header itself. The ICMPv6 Echo Reply header is 8 bytes.
Therefore:
The maximum IPv6 packet is 65,575 bytes (max payload of 65,535 + header of 40).
The maximum IPv6 payload is 65,535 bytes.
The maximum ICMPv6 Echo Reply body is 65,527 bytes. (max payload of 65,535 - ICMPv6 Echo Reply Header of 8).