How is the post token generated in GWT? - gwt

I have requests like
5|0|7|http://localhost:8080/testproject/|29F4EA1240F157649C12466F01F46F60|com.test.client.GreetingService|greetServer|java.lang.String|myInput1|myInput2|1|2|3|4|2|5|5|6|7|
I would like to know how GWT generates the md5 value 29F4EA1240F157649C12466F01F46F60? Is it based on the client ip and date? Can anyone point me to the correct code? I just find stuff regarding the history token, but that looks different to me.

OK, after some research I think I found the answer.
The keywords you should have been looking for are "strong name" (or "strongName") and/or permutation, since it seems that with the RPC request they send out the permuatation strong name (that MD5 hash), so that you can possibly distinguish on the server side from which permutation the request was send.
The core function is Util.computeStrongName, it computes an MD5 hash (d'oh) of the provided byte array, with the added catch:
/*
* Include the lengths of the contents components in the hash, so that the
* hashed sequence of bytes is in a one-to-one correspondence with the
* possible arguments to this method.
*/
From there, I tracked back to the linkers and then to PermutationResult which is feeding Util.computeStrongName via this function:
/**
* The compiled JavaScript code as UTF8 bytes.
*/
byte[][] getJs();
Eh, I hope that was at least a bit helpful ;) If this still doesn't answer your question (or you were looking for something different), try in trunk/user/src/com/google/gwt/user/client/rpc (start in RpcRequestBuilder.java).

As Igor said, GWT uses MD5 hashes of your application code to produce unique names for each permutation of each version of your application. The specific hash you referenced is a part of the GWT RPC request payload that identifies a .gwt.rpc serialization policy file on the server. That policy file says which Java objects can be serialized as part of the request, response, or thrown exceptions in the GWT RPC service.

Related

Varnish 3.0.3 req.hash_always_miss vs Vary

I'm trying to build a system that can purge and regenerate URLs as required for a particular system. I previously was having issues with purging when the system located the object by hash but missed the variant as I didn't have a "purge;" in my vcl_miss (only in my vcl_hit, some guides/example vcl files do not mention this need but the main documentation does here).
What I'm trying to figure-out is if I need to do something similar for a REGEN call. From my understanding, "set req.hash_always_miss = true;" will mean that the old hash is missed and a new hash object is generated. Subsequent calls will find the new hash, but may still miss that object if there is not an appropriate variant in the cache.
Could someone confirm for me whether a subsequent request missing the variant in the new object will lead directly to a cache miss and fetch, rather than finding any of the variants from the previous object?
hash_always_miss will only influence the current/ongoing request and the cache contents that it replaces. A fetch will always happen, and the object will be put into the cache using the same rules as any other miss/fetch sequence.
The "old" other variants of the same hash are still valid objects and will be served to a client indicating request headers matching the varied headers.
hash_always_miss will replace the current variant, and nothing else.
To answer your question, the second part of your sentence is most correct.

How to generate stream of custom symbols instead of ints in lexer?

I am asking for gplex, however it might be the case, the solution to the problem works for other lex-derived tools.
I wrote all rules, everything is fine with one exception. The type of the scan method of the generated scanner is int, and I would like to be MySymbol (which would consist of id of the token -- INT, STR, PLUS, so on, its value, and possible location in the file).
I checked the samples (not many of them), but they are very simplistic and just write out the fact rule was matched, I've read the manual, but it starts from parser perspective and for now I am a bit lost.
One of my rules in lex file:
while { return new MySymbol(MyTokens.WHILE); }
All I have now is scanning phase, I have to finish it, and then I will think about parser.
Yacc and Yacc-like tools (here GPLex) relies on side effect. Normally you could think of returning the data, but here you are returning token id, and any extra data has to be "passed" via special variables like yyval.

using protobuf as a textual configuraton file

I recently encountered a very large mission-critical project where all the configuration
files were defined using textual protobuf definitions. The configuration files are meant to be
human readable and editable.
For example
message ServerSettings {
required int32 port = 3022;
optional string name = "mywebserver";
}
Personally I found this humorous.
But is it in fact a reasonable keep-it-simple technique, or clearly moronic ?!
In other words, are there REAL, ACTUAL problems with this ?
If that is the text proto if format, then... Whatever, I guess. If it works, then it is as reasonable as any other serialization format.
If that is meant to be proto schema, then it is illegal (the value after the = is meant to be the field number).
Json or XML might be more typical, but as long as it works it isn't "moronic". So the ultimate question is: does it work?
I think it's quite clever. I am guessing they pass it through protoc --encode to generate a binary which is what is actually parsed.
Pros:
1. Code is generated to parse configuration
2. Type validation
3. More robust configuration file compared to a key/value as it supports structs, unions, maps and arrays
4. The configuration data is now serializable meaning it can be easily exposed to an RPC or IPC interface.
Cons:
1. The syntax can be a little verbose for maps/arrays.
2. It requires protoc to be installed on the target as well as libprotobuf.so if you are on a system with tight memory limits.

How to hash in CFMX_COMPAT in c#

An existing coldfusion website is to be converted to dot net.
In the coldfusion code, the password is hashed using its hash() function with no algorithm:
SomePassword = '#hash(fldPassword)#'
I found this document, saying the default encryption is
CFMX_COMPAT: Generates a hash string identical to that generated by
ColdFusion MX and ColdFusion MX 6.1 (default).
There are some articles actually telling me how to decrypt.
According to Macromedia, The ColdFusion Encrypt function uses an
XOR-based algorithm that utilizes a pseudo random 32-bit key based on
a seed passed by the user as a parameter to the function. The
resulting data is UUencoded.
You'll need to uudecode the encoded value first
http://www.eggheadcafe.com/printsear...asp?linkid=351
and then XOR it using the key it was encrypted with.
http://www.java2s.com/Code/CSharp/La...deamessage.htm
If you dont have the key - your wasting yuor time.
But, how to make it work? I don't think there is any key. All I can see is '#hash(fldPassword)#'. Please help. Thanks.
There are some articles actually telling me how to decrypt.
Hashing and encryption are not the same thing. Encryption can be reversed. You can recover the original value if you have the right key, etectera. Whereas hashing is a one way trip. Once hashed, the original value cannot be recovered. (Well .. in theory. Some of the weaker hashing algorithms have been broken.) So you cannot "decrypt" a hashed value. But you can duplicate the obfuscated result string.
I found this document, saying the default encryption is CFMX_COMPAT
Actually it refers to the default algorithm. However, I am not so sure that description is correct. (Edit: As Rasmus correctly points out, it does say the default is MD5) However, CF9/7 default to MD5 anyway. Even when the algorithm is CFMX_COMPAT. So in either case, a simple MD5 hash in C# would give you the same result.
ie These all produce identical results ie 098F6BCD4621D373CADE4E832627B4F6.
#hash("test")#
#hash("test", "cfmx_compat")#
#hash("test", "md5")#
If I read the documentation correctly, CFMX_COMPAT hashing is just MD5.
So:
byte[] hash = MD5.Create().ComputeHash(fldPassword);
It should be easy to verify if you have access to a ColdFusion installation.

How to describe Input Parameter in a RESTful Web Service

Im developeing a RESTful Service in which Processes can be executed and proivde a resulting calculation. For this i have modeled the process itself as a Resource (Example: /processes/translate). I want to execute the process by sending a GET request with appended Input Parameter as Query Parameter (Example: /processes/translate?input1=xxxx&input2=xxxxx).
Each process has different Input Parameter which are defined during the process creation in the backend. My Question is how should i document or describe which inputs are needed to execute a process in machine readable form. For Example in XML.
Until now ive integrated atom:link elements in the Representation. i thought that maybe including XFORM could be a soluttion?
Best Regards
Andre
I would not model this with a GET. While it's the easier solution, it's also (IMO) the least RESTful. I would have clients POST a document describing what they want you to translate and your service sends them back a URI where their answer can be found (some translations might take a while).
Example (ommiting a lot of HTTP headers/context)
POST /processes/translate
Content-Type: application/xml
...
<translation-request>
<input1 type="type1">....</input1>
<input2 type="type5">....</input2>
</translation-request>
Response:
200 OK
Content-Location: /processes/translate/jobs/1234
....
That's always an interesting question. We have a project called RESTx (http://restx.org), with which you can create RESTful web services very easily. You can write custom component code in either Java or Python and then create RESTful resources by sending parameter sets to the server, which are then stored. Each parameter set gets its own URI, though, so you can always just run the code with those parameters by accessing the new parameter set's URI.
Importantly, the entire RESTful API, is automatically created. RESTx examines the component code and then assembles the API description. We decided to describe parameters in a way that is human as well as machine readable. You can see examples of what that looks like in a browser or in plain JSON.
I'm the lead developer on that, so please feel free to contact me about any questions you might have.