In response to Tihomir reporting this issue on #guvnor and further poking by zenix I logged the following headers:-

===> Fail
http://127.0.0.1:8888/org.drools.guvnor.Guvnor/guvnorService
 
POST /org.drools.guvnor.Guvnor/guvnorService HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Length: 154
Content-Type: text/x-gwt-rpc; charset=utf-8
Referer: http://127.0.0.1:8888/org.drools.guvnor.Guvnor/Guvnor.html?gwt.codesvr=127.0.0.1:9997
Cookie: standalone_usage=true
Pragma: no-cache
Cache-Control: no-cache
7|0|4|http://127.0.0.1:8888/org.drools.guvnor.Guvnor/|6808FDC8A4FA3491026441B59E4DB72A|org.drools.guvnor.client.rpc.RepositoryService|subscribe|1|2|3|4|0|
HTTP/1.1 400 Bad Request
Content-Type: text/plain;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Wed, 23 Mar 2011 20:11:04 GMT
Server: Apache-Coyote/1.1
Connection: close



===> Success
http://127.0.0.1:8888/org.drools.guvnor.Guvnor/guvnorService
 
POST /org.drools.guvnor.Guvnor/guvnorService HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.15) Gecko/20110303 Ubuntu/10.10 (maverick) Firefox/3.6.15
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
X-GWT-Permutation: HostedMode
X-GWT-Module-Base: http://127.0.0.1:8888/org.drools.guvnor.Guvnor/
Content-Type: text/x-gwt-rpc; charset=utf-8
Referer: http://127.0.0.1:8888/org.drools.guvnor.Guvnor/Guvnor.html?gwt.codesvr=127.0.0.1:9997
Content-Length: 154
Cookie: standalone_usage=true
Pragma: no-cache
Cache-Control: no-cache
7|0|4|http://127.0.0.1:8888/org.drools.guvnor.Guvnor/|41FA1D8B82DBBBC875605A4A29670D99|org.drools.guvnor.client.rpc.RepositoryService|subscribe|1|2|3|4|0|
HTTP/1.1 200 OK
Content-Disposition: attachment
Content-Type: application/json;charset=utf-8
Content-Length: 48
Date: Wed, 23 Mar 2011 20:15:38 GMT
Server: Apache-Coyote/1.1


So, the required GWT "X-GWT-Permutation" header is definately missing.

I've posted a question to the GWT forums to see if its a known issue.

Has anybody experienced this in "Web" mode?

Cheers,

Mike

On 3 February 2011 16:52, Michael Anstis <michael.anstis@gmail.com> wrote:
Anybody else see these errors in Guvnor (5.2.0.M1)?

ERROR 03-02 16:35:38,914 (LoggingHelper.java:error:70)      Blocked request without GWT permutation header (XSRF attack?)
java.lang.SecurityException: Blocked request without GWT permutation header (XSRF attack?)

GWT2.1 introduced support for preventing XSRF attacks; see here.

I get these errors quite regularly (Firefox 3.6.13, Ubuntu 10.10) both in hosted and web modes (Tomcat 6.0.30). I've looked through the GWT source and (at least in hosted mode) the additional HTTP header to prevent these errors are added as part of GWT's client-side serialisation before POSTing to our RepositoryServiceServlet. I can't therefore explain why I therefore get these errors. In my experience; once the error has occured and dismissed the page\function\operation can be repeated without the error re-occuring (i.e. view "Business rule assets" in the Tree Browser and it may fail the first time; however works the next and the next... until the server is restarted, when the cycle continues). The errors can be completely removed by overriding GWT's com.google.gwt.user.server.rpc.RemoteServiceServlet.checkPermutationStrongName to not check the HTTP header and simply return; however this effectively removes XSRF protection (although not implemented pre-GWT2.1 and hence not in Guvnor <=5.1).

I put the email out so people are aware (we switched to GWT2.1 for 5.2.0.M1) so our users may start to report the same error; in which case we should perhaps be prepared for the quick fix...

With kind regards,

Mike