RPC format relies on eval for large payloads and long strings #9578
Comments
|
Any updates on this? We are using GWT at work and would love to finally get rid of the |
|
I do have this patch somewhere, but can't recall where it stalled, probably in making sure that other browsers tested well. Instead, most of my time in this area has been spent on a feature-complete replacement for RPC, based on APT instead of Generators. This is at https://github.com/vertispan/gwt-rpc/, and while it isn't ever going to get to 100%, it is probably at about 70% now, and should be able to reach 80-90% (minus just a few features like reflection/violator pattern to modify private or final fields directly, so bean-like getters and setters or custom field serializers will be required). I'll see if I can find the patch, but this work was not needed for the new RPC at all, which doesn't mess with json strings at all at this time. |
|
So that'd mean that without this patch we'd be kind of stuck with |
|
No - while the linked project is intended to be compatible with GWT 3, it is already compatible with GWT 2 (and that isn't expected to change). |
|
Hello. I'm not sure if this is the correct place for my question, but it was the only place more relative to what I'm struggling with. And to not open a new issue with relatively the same problem. So, my problem is related to CSP, specifically 'unsafe-inline' rule, because now, in my situation compiled application violates it. Whether I'm using 'xsiframe' or 'direct_install' linker, the situation is related to the fact I'm using deferred split modules, which are injecting via inline js script to iframe, and in this way violate the 'unsave-inline' rule. I could use sso linker, but it's not a case, because it does not support several modules. Can anyone suggest maybe some linker or approach, to fix this issue, please? Regards. |
|
@Zim123 Let's discuss on #8197 or, better, https://groups.google.com/forum/#!forum/google-web-toolkit |
|
We are hitting this issue (9578) as well. We recently had a security scan find the use of unsafe-eval in our GWT-based application. Upon removing unsafe-eval and setting the gwt.rpc.version to 8, everything worked except for requests with large responses > 32k, which executed an eval instead of safeEval. It appears that ServerSerializationStreamWriter.LengthConstrainedArray is used to conditionally change the response when the size is greater than 32k which resets the rpc version back to 7 and uses a special "PRELUDE" concatenator and flags the stream buffer as 'javascript'. There are comments in this thread and in the code which indicates this is only needed for IE 6/7 both of which are no longer supported. We quickly built GWT locally to test with larger size constraint and this fixed the issue we were seeing. Do you know if a fix for this issue would be included in the next release? Section of code that I referenced regarding the length check: |
|
Yes, I think we could probably remove that workaround entirely - are you interested in putting together a patch for it? |
|
I appreciate your willingness to accept a patch. Unfortunately my company is not able to prioritize the work to create a patch at this time. I will monitor this issue and let you know if that changes. |
|
how do you set gwt.rpc.version to version 8? |
|
#9961 provides a workaround for this issue, by letting These are both Java System Properties, so how you set them will depend on how you start your server. If you can pass JVM arguments (such as through |
Make the RPC chunk size configurable through a system property `gwt.rpc.maxPayloadChunkSize`. This allows implementors to circumvent the RPC protocol version to fallback to version 7 on large payloads. Which in the current client implementation uses unsafe javascript eval, preventing proper operation on sites with CSP's restricting `unsafe-eval`. Workaround #9578 Co-authored-by: codemasterover9000 <[email protected]>
|
Sorry, this isn't fixed, but the workaround is improved. |
|
We should raise these limits to their max and update the default version to 8 for the next release - there's no reason to keep them so low today given the current state of browsers, will make it easier for users trying to use stricter CSP rules, and will make the transition more seamless once we finish removing this old logic. |
GWT version:2.8.2
Browser (with version):any
Operating System:any
Description
From #8197 (comment), it turns out that RPC's server serialization stream writer still assumes that the browser needs concatenated strings and arrays.
However, the strings were concatenated to support hosted mode (which apparently at the time couldn't support larger than 64kb strings), but that appears to have been fixed, and arrays were split to support a bug in IE6/7 where long arrays couldn't be eval'd, but again, we don't support IE6/7 any more.
So, we don't really need it. Additionally, this is an issue since it violates CSP, as eval isn't particularly safe, and some sites would like to forbid its use to further protect their data and their users.
I'll try removing these hacks and confirm that eval is no longer called (except of course in browsers that do not support
JSON.parse), and confirm that running dev mode can handle giant strings correctly as well. This should remove the ability of the server to produce streams older than version 8 (sinceServerSerializationStreamWriter.writeHeaderis the only code that should be writing out a version for the client). Will leave in support on the client for reading older streams, as we've done in the past.The text was updated successfully, but these errors were encountered: