Embedding PHP in GWT-generated files?
I got to wondering if it would be possible to add PHP to the output of the web tookit compiler. In short, the answer is yes. I’ll have to play around with it some more to see what code ends up in cached files and what code goes to nocache files, since that would be rather important.
I tried adding a PHP block to JSNI code. Oddly enough, the compiler complains about the bad syntax. Which is fine since it is bad javascript syntax, to some extent… If nothing else, it’s an inappropriate place for random HTML tags. The compiler will not complain, though, if you stick the code into an HTML comment. But comments get stripped out during obfuscation, so this doesn’t matter.
My really simple test case was the following:
private static native String nativeCode() /*-{
someVar = “< ?= 'a PHP string'?>“;
return someVar;
}-*/;
I then had to add:
AddType application/x-httpd-php .html
to the .htaccess file. Now when I load the GWT application, I get a value set by a PHP function call. This is a basic, and rather limiting sort of example. This code ended up in the cachable file, which could be a problem if you expect the value to actually be dynamic. I’ll don’t know what determines which code is cachable and which is not, so I’ll have to experiment further with it.
This is also strange because of the GWT compilation step. Trying to use double quotes within the PHP block could be challenging. It’s a good place for an include statement, avoiding any use of double quotes. The problem is that the line needs to parse as valid javascript. If you escape the double quotes, then the PHP won’t execute properly.
Written in this way, it limits you to setting a variable to a string value, but your PHP could always return a string such as “\”; someOtherVar = 0; someVar=\”" that would let you mess around with other variables within javascript, assuming you can write it such that it is useful after obfuscation of the javascript.
It does make a rather dreadful combination of languages. But then if you’re using PHP with GWT, you already have such a beast. It is probably more useful in most cases to put your PHP into the main html file for the application, define javascript properties there, then reference those properties in JSNI calls.
The place where I can imagine this being most useful would be in generators. Adding PHP blocks outside of javascript blocks would avoid the problem of creating javascript that won’t parse properly during compilation. Done correctly, this could even provide a good way to cause the GWT compiler to generate PHP code to handle GWT-native RPC calls without having to worry about any changes in (or lack of documentation on) the wire protocol. This is, of course, speculation on my part. I haven’t researched the situation enough yet to actually do anything with it, but it seems like a really exciting potential.
Feel free to share any thoughts on this.
October 8th, 2007 at 5:22 am
Wouldn’t be this an entry for code injection?
Imagine that you construct an String with a code a client sent to server. This string looks like: “”, or whatever else. If you force the result of GWT execution to be interpreted by Apache/PHP module then a bad intentionated user can execute PHP commands at your server. Or am I wrong? Thanks for you comments.
October 10th, 2007 at 2:55 pm
Actually the intention here was to find a way to have the GWT compiler add PHP code into the generated files. Then Apache could parse the PHP when requests hit those files. So RPC calls would request the URL with the Java/PHP RPC handler functions and be able to do native RPC calls… If you could get the compiler to output PHP at the same time it was outputting Java, then perhaps the files could be more cross-platform. Of course, it would probably be better to just generate PHP files during compilation.