Very worried this question may be abused, but here goes!
My server is receiving some data through a GET request in the URL, which has been encoded in some manner, I thought it would be base64 but that is not the case.
I would like to write a js function to accept this string and try all possible encodings/decodings.
Please help!
The data is in this sort of format: ZHpuxRiviOUGeOKTKdw
There is the potential it is encrypted, if that is the case I am not asking for help in decrypting it!
EDIT: my goal is not to write a perfect algorithm which can do this automatically - I simply want to try x top most popular decodings of this string and print them out.
You can't really do that, how would you know if ZHpuxRiviOUGeOKTKdw wasn't actually the string? If this is your server and this is data you're receiving then you should know how the string is encoded based on what your application does.
Related
I've seen this post already, and it didn't quite shed much light on what is going on.
I have a mongo server, that stores information about classes, what times and days they meet and what not. I also have an express server, that interacts with and returns this data.
When I look at the data in Robo3T (a mongo data viewer), it is formatted - as it should be - like so:
2018-09-07 04:00:00.000Z
But when the data comes back to the server, it comes back like this: 2018-09-07T04:00:00.000Z
What is causing this? In no way do i make any attempt to format this data before I display it. I also checked the server output, which returns it the same way:
I guess my question is, why is this happening? and is this impacting my ability to query results from mongo based on a date range? Any assistance would be much appreciated, thank you.
Robo 3T just happens to display dates that way. This does not mean that it actually is stored that way. When you switch the view to "text mode", you will see that it actually is ISODate("2018-09-07T04:00:00.000Z") (with the T).
This format is actually the date format string that is used in JavaScript. And yes, the T is required. See What are valid Date Time Strings in JavaScript?
I have a class Message which can be serialized when the data goes through the network, I currently use JSON, mostly because I use JSON for everything. (webservice, sockets).
I want to improve the serialization to make it as good as possible, I believe improvments are possible here.
The aim is to make the transport string lighter, especially when used by sockets (video game), because it will be used for everything, every response client/server or server/client and even inside the server or client methods, it's the usual way to provide data.
The Message is a complex object that can also contain other object instances, like a MessageLang, which will be responsable to translate a sentence on the client based on a code.
So far it works fine, here are the results:
Socket server emit with simple string:
verbose: websocket writing 5:::{"name":"user.newAuthenticated","args":["Respond to emitter"]}
Socket server emit with simple message instance:
verbose: websocket writing 5:::{"name":"user.newAuthenticated","args":["{\"m\":\"Respond to all clients\",\"d\":{},\"s\":1,\"t\":\"m\"}"]}
Socket server emit with complex message instance:
verbose: websocket writing 5:::{"name":"user.newAuthenticated","args":["{\"m\":{\"m\":\"__12\",\"a\":{\"field\":\"name\",\"min\":3,\"max\":20}},\"d\":{\"key\":\"fakeKey\"},\"s\":1,\"t\":\"m\"}"]}
The complexe message would render the following sentence:
The min length of name is 3. Max length is 20. and would contain the key: "fakeKey" in data. Just to explain how it works.
As you see, the message get bigger and bigger and it is normal, but I would like to know what I can do to make a better serialization here:
Delete the message itself when there aren't (empty)
Delete the data when it's empty as well
Delete the status when it's false (because it's the default value)
I see a lot of \ in the socket log because it is JSON, I believe that's a problem, because each time I'll add something I'll get extra characters that I do not want. Maybe the JSON isn't a good choice and I should serialize differently, first in JSON like the examples at the top, but then in something else, maybe kind of binary, if it takes less space.
What do you think?
And if it would be a good idea to encrypt somehow the message in another format, would the cost of the encryption be worth it? Because encrypt it would take a bit of time as well, so I'm just wondering if it wouldn't just move the issue, like it would take less time to send the message through socket because it would be lighter, but we would use more time to encrypt it. Just wondering.
My guess is that your message object has two fields (name and args).
The first stop to reduce the length of the message is to get rid of the (pretty useless) outer object and replace it with an array. So an empty message
{"name":"empty","args":[]}
would become
["empty",[]]
or even
["empty"]
The next thing is that you have a bug in the serialization of the arguments. Instead of sending JSON, you wrap the JSON data in a string. Example: In the authenticated case, you send
{"name":"user.newAuthenticated","args":["{\"m\":\"Respond to all clients\",\"d\":{},\"s\":1,\"t\":\"m\"}"]}
but you should send
{"name":"user.newAuthenticated","args":[{"m":"Respond to all clients","d":{},"s":1,"t":"m"}]}
instead. Now the question is whether args is a list of a single object. If it's always a single object, then you could get rid of the [] as well. With my suggested change from above, that would give you:
["user.newAuthenticated",{"m":"Respond to all clients","d":{},"s":1,"t":"m"}]
which is pretty good IMO. If you can make the (de-)serializer handle default values properly, you can reduce this to:
["user.newAuthenticated",{"m":"Respond to all clients","s":1,"t":"m"}]
(i.e. we can omit the empty d property).
For a MMO, I think a minimum of data must be sent to the client. If a socket is called 2xx/3xx by sec, you must reduce the size of the data sent through the socket as most as possible.
On another hand, it also consummes resource to encrypt the object on the server side to send a minified version of the object... Wouldn't it be better not to reduce it and to send an object not reduced so we don't spent resource to encrypt it?
This question already has answers here:
How to compress/decompress a long query string in PHP?
(9 answers)
Closed 8 years ago.
I current have a URL like this
http://blahblah.com/process.php?q=[HUGEEEEEEEEEEEEEEEEEEEEEEEE STRING of 5000 chars]
My goal is to convert this something like
http://blahblah.com/process.php?q=[less charcters]
The first question:
How do I perform a function (encryption function for instance) on my GET variables before it is sent to the action page?
I've seen many questions asked with a similar topic.
The second question:
Assuming, I can do the above by some means (maybe by jQuery/JavaScript or something). How do I compress in the index.php page and decompress in the process.php page?
My attempt:
Searching for functions with fixed lengths:
I've looked at some encryptions that maintain the string size for ex. md5() gives a standard length that is short and tidy even for an extremely huge string. But unfortunately md5 cannot be decoded easily. Is there any other such function that I decode and which has a fixed length? If so, I could use that assuming I know a way to do Step 1.
EDIT: I write a request not to mark as a duplicate of that question and a question which hasn't been answered have specifically been asked again.. Please read #Jeremy 's comments, he was following this post.
I personally think it is best to use POST to send the data to the page. I am pretty much sure you can not use anything like MD5 to 'compress' the data because what MD5 does is hash the data, so it will look at your data run an algorithm to create this fixed length hash.
However, there is an extremely small possibility that two data sets will create the same hash, therefore it seems to me impossible to reliably decrypt MD5 or other similar hashes. Check out this page for more on hash collisions.
Your problem is that you are using the internet the wrong way. The URL is limited (and it depends on the browser), so don't event to try to use long URLs - even when you want to shorten it.
Please keep in mind, that we are using the WordWideWeb for a long time and if you come into a deadend you just have to rethink your problem. Maybe you are using your current technology the wrong way.
So, use POST instead to transfer your data (as others mentioned before).
If you want to "compress" your data you should use a zip like thing and then you must make that URL confirm like BASE64 afterwards. This is not suitable in any way and completly hideous. (And of course it can not guarantee the length of your URL).
MD5 is a hash not a compression thing. MD5 is not reversable. Once you hash something you can not go back again. This is not a magical way to compress tons of megabytes into a single short number. This is to have a short thing that can tell if the original data was modified (if you do that twice).
See http://en.wikipedia.org/wiki/Hash_function
See http://en.wikipedia.org/wiki/MD5
BTW: It is the same as How to compress/decompress a long query string in PHP?
I was evaluating the various ways in which the big guys implement auto suggest. These are my observations.(Search string used was "ab") Questions towards the end.
Yahoo tries something like this, where the response was a JSONP. Response is readable and serves the purpose.
Yahoo's response
yasearch({"q":"ab ","gprid":"Y435dN7TRFqnYqQhnBueJA","f":["k","m"],"r":[["ab de villiers",0],["ab exercises",0],["ab king pro",0],
["ab infi-net internet banking",0],["ab mujhe raat din",0],["ab workouts",0],["ab mp3",0],["ab meri bari",0],["ab ke baras",0],["ab meri baari",0]]})
Bing had a similar approach. Returns an "if" block, sa_inst.apiCB() seems to be a function which would process the JSON. Again response is readable and legit.
Bing's response
if(typeof sa_inst.apiCB == 'function') sa_inst.apiCB({"AS":{"Query":"ab","FullResults":1,"Results":[{"Type":"AS","Suggests":[{"Txt":"ab<strong>p</strong> <strong>news</strong>","Type":"AS","Sk":""},
{"Txt":"ab<strong>bottapp</strong>.ab<strong>bott</strong>.<strong>in</strong>","Type":"AS","Sk":"AS1"},{"Txt":"ab<strong>t</strong> <strong>travels</strong>","Type":"AS","Sk":"AS2"},{"Txt":"ab<strong>p</strong> <strong>ananda</strong>","Type":"AS","Sk":"AS3"},
{"Txt":"ab<strong>hibus</strong>","Type":"AS","Sk":"AS4"},{"Txt":"ab<strong>p</strong> <strong>maza</strong>","Type":"AS","Sk":"AS5"},{"Txt":"ab<strong>b</strong>","Type":"AS","Sk":"AS6"},
{"Txt":"ab<strong>outgoogle</strong>","Type":"AS","Sk":"AS7"}]}]}} /* pageview_candidate */);
Now comes Google. Response is sent as 2 JSON objects(separated by /""/). Most of it is unreadable.
Google's response
{e:"XteVUYKqDoKHrAfdz4D4Aw",c:0,u:"https://www.google.com/s?hl\x3den\x26gs_rn\x3d14\x26gs_ri\x3dpsy-ab\x26tok\x3dvsobDhICRmdcnY7ayKTGng\x26cp\x3d2\x26gs_id\x3dd\x26xhr\x3dt\x26q\x3dab\x26es_nrs\x3dtrue\x26pf\x3dp\x26output\x3dsearch\x26sclient
\x3dpsy-ab\x26oq\x3d\x26gs_l\x3d\x26pbx\x3d1\x26bav\x3don.2,or.r_cp.r_qf.\x26bvm\x3dbv.46751780,d.bmk\x26fp\x3d2647af89de6b6c61\x26biw\x3d1366\x26bih\x3d453\x26tch\x3d1\x26ech\x3d2\x26psi\x3dVteVUcYuzOGsB6LpgdgB.1368774484351.1",
p:true,d:"[\x22ab\x22,[[\x22ab\\u003Cb\\u003Ec\\u003C\\/b\\u003E\x22,0,[]],[\x22ab\\u003Cb\\u003Ec news\\u003C\\/b\\u003E\x22,0,[]],[\x22ab\\u003Cb\\u003Eercrombie\\u003C\\/b\\u003E\x22,0,[]],[\x22ab\\u003Cb\\u003Ecya\\u003C\\/b\\u003E\x22,0,[]]],
{\x22j\x22:\x22d\x22,\x22q\x22:\x22t8z6h8KhWvbkEX6xablxgYxDUq4\x22,\x22t\x22:
{\x22bpc\x22:false,\x22tlw\x22:false}}]"}
/*""*/{e:"XteVUYKqDoKHrAfdz4D4Aw",c:-1,u:"https://www.google.com/searchdata?hl\x3den\x26gs_rn\x3d14\x26gs_ri\x3dpsy-ab\x26tok\x3dvsobDhICRmdcnY7ayKTGng\x26cp\x3d2\x26gs_id\x3dd\x26xhr\x3dt\x26q\x3dab\x26es_nrs\x3dtrue
\x26pf\x3dp\x26output\x3dsearch\x26sclient\x3dpsy-ab\x26oq\x3d\x26gs_l\x3d\x26pbx\x3d1\x26bav\x3don.2,or.r_cp.r_qf.\x26bvm\x3dbv.46751780,d.bmk\x26fp\x3d2647af89de6b6c61\x26biw\x3d1366\x26bih\x3d453\x26tch\x3d1\x26ech\x3d2\x26psi\x3dVteVUcYuzOGsB6LpgdgB.1368774484351.1",
p:true,d:"{\x22snp\x22:1}"}/*""*/
Are those hex codes or what do you call them?
Why is there a need for 2 objects to be returned?
What is the need for encoding the JSON?
Which is the ideal format for JSON among these three?
Any thoughts on this are welcome.
Are those hex codes or what do you call them?
Assuming you are referring to Google's response, I believe they are;
the \x00 format represents hex values
the \u0000 format represents unicode values
Why is there a need for 2 objects to be returned?
Not sure, one guess is that one of those objects is a list of recommendations, and ther other is a list of previous searches you have made.
What is the need for encoding the JSON?
Basically, these guys would have needed a way of delivering structured data from their server to the client. Only two real possibilities come to mind; XML and JSON. In this case, JSON would probably always be the winner as it uses less bandwidth and can be dealt with in Javascript easier.
Which is the ideal format for JSON among these three?
This is only opinion, but following from above, the ideal situation is the least amount of data, so based on that alone, I think Yahoo wins.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How can I obfuscate JavaScript?
I was browsing some sites and found really interesting thing. I am just starter in this coding and never seen such a thing, so I was wondering is it encrypted or encoded or packed or is there anything else?
Script sample:
V10861992380165541086199238016554108619923801655410861992380165541086199238016554108619923801655410861992380165541086199238016554='13047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395130473894741439513047389474143951304738947414395'
or here is screenshot of one really long thing, couldnt even snap it all over my screen.
http://snpr.cm/8KznHp.png
http://snpr.cm/xOLfRE.png
Can anyone tell me what are these, and how can I do the same?
Do I need to pay for an program or something? Thank you for understanding.
All the line or code does is create a variable starting with V and put the number in it. Without seeing the rest of the code I cant tell if it is just encoded or encrypted as well, but if you notice the string is just repeating the number 1304738947414395.
You can definitely do a simple encoding by your self. A simple encoding is to put all the javascript code in a string like aaa="document.write('blah')" and then say aaa="atob(aaa) which converts the original string to base64. Save the base64 string and then place it in an eval statement like eval(btoa(aaa)) that converts it back to text, and then the eval executes the text. When it's finished you have some encoded mildly obfuscated code.