I'm sending some pre-encrypted strings (AES) to a REST API, this is data that has been encrypted by the client. I am storing the data, and never decrypting it on the server side.
I will hand it back to the client later.
My initial thought was to use base64 encoding to ensure the data survives the form post. Is this the correct way to do things?
You do not need any special encoding to POST data to a server, as there is no restriction to what characters you can use.
If you choose to send the encrypted data as binary data, you should specify content-type header to be application/octet-stream.
Related
I would decode this message sent to our national tax office. I have no clue how to start it. Seems it is a SAML encoding, I do not know much about SAML.
But in the content either xml or json is.
I tried this website to decode, but it did not do it.
https://www.samltool.com/decode.php
How to decode?
The HTTP-Redirect binding uses the DEFLATE encoding. The SAML message has been sent using the HTTP-Post binding. This means that the form data will include either a SAMLRequest or SAMLResponse form variable. This form variable must first be URL-decoded and then base-64 decoded to get the resultant XML.
I am new to backend service and I was tracing API calls from a banking website. Normally, I have seen parameters in POST requests being encoded with base64 encoding. However, I came across a type of request where the date was encrypted with a type of encoding that I am unable to figure out.
For date: 19/12/2018 the encoding is: U2FsdGVkX1/o1qw9zIiZBHLAbGck6j15wwUZ/z/zLqw=
and for date: 18/12/2019 the encoded string is: U2FsdGVkX1/mo5+FfuqqqbUtCsdFObB8eKvyosc4b8E=
I am aware of only base64 encoding, but since I am unable to decode this with base64, it seems this is using something else. Appreciate if anyone can help and share some knowledge about the different ways in parameters can be sent to backend in a secret manner.
The encoding/encryption seems to be happening from the frontend side and I feel this could also be an encrypted string with seed sent in a separate parameter. Appreciate if someone can atleast share a list of possible algorithms that I can look into to understand the request sent and create my own requests.
I have difficulty in understanding how this header works.
Briefly my question is
If i am requesting a post to certain resource then let's
Say in 1st case response is some json string and in 2nd case response is a .jar file.
1.Should client include accept-header:gzip,deflate in both cases while sending HTTP request,knowing that first one results in json string?
2.What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems?
3.what happens if i include accept-encoding:gzip in first case where json string is received. So i receive a zipped data as my response(i am not even sure if get zipped data or some encoded data as response.I think zipped data means something zipped like .jar/.zip and encoded data means Encoded data of the original data ,which one is happening zipping or encoding)?
4.Lets say the server sends the response with Contentype header as "application/octet-stream". Now is it must to use accept-header:gzip,deflate
A client can use Accept-Encoding HTTP request header to tell the server that it can accept a compressed response.
The server can use the request header to decide if it should send a compressed response or not. It can ignore the header and always send a non-compressed response (possibly less efficient). It can ignore the header and always send a compressed response (risking giving a client a response it can't decode).
Should client include accept-header:gzip,deflate in both cases
I can't think of any reason to not tell the server that a client can handle a compressed response (assuming that fact is true).
What if the response is already zipped,now zipping the response over the already zipped data doesn't create problems
It might be a waste of processor power for little or no saving in bytes.
That's not a reason for the client to say it can't handle a compressed response though. That's a decision to be made on the server.
what happens if i include accept-encoding:gzip in first case where json string is received.
Then the client has told the server that a compressed response is acceptable.
So i receive a zipped data as my response
The server might send a compressed response. It might ignore the header.
i am not even sure if get zipped data or some encoded data as response
There isn't an "or" here.
The data is encoded using a compression algorithm.
Lets say the server sends the response with Contentype header as "application/octet-stream"
That just means the server doesn't know what type of data it is sending. Instead of saying "This is JSON" or "This is a jar file" it is saying "I dunno what this is, it's just a stream of bytes to me".
Now is it must to use accept-header:gzip,deflate
It doesn't make a difference.
The server can compress the data. It can send uncompressed data. It can use the Accept-Encoding request header to decide which of the two.
Yes, why not? If the JSON payload is big, compressing it will make a lot of sense.
It's just overhead.
You might receive gzipped data - not a ZIP file. You may want to read RFCs 7230 and RFC 7231 for details.
The internet media type of the payload is completely independent of the content coding.
I am trying for a way to pass binary data to a server over http, via the URL field in the browser. Is there a way to bypass the automatic http encoding done by the browser so I can just encode the data by myself.
e.g.: Instead of the byte with value 48, to fill in the URL %30 so that the browser doesn't re-encode the url and I end up with %2530
Solved: To whom may encounter similar problems in the future. You can do so by using wget parameter
--restrict-file-name=ascii
Which basically ensures that '%' won't be escaped
Use base64 encoding, that's what it's designed to do.
I managed to do so, by writing my own tcp client to connect to the http server and transmit the request, by inputting it manually.
Use the base62 encoding.
The encoded string doesn't contain any character that will be URL-encoded.
Is it possible to send binary chars feom the client to server via post ?
Should i encode it in the client before sending ?
Or something else ?
Yes it is possible to send binary data from client to server. That's exactly what happens when you use a form with enctype="multipart/form-data" to upload files. Binary data is sent. It is not necessary to encode data on the client before sending. Another example is writing raw bytes in a POST request body which could be read on the server using Request.InputStream.