We don't have a single setting at the DataSource level that sets this property for all fields - you have to set it for each field you care about directly.
I have an application that is retrieving data and I am adding some additional filters on the retrieve. The URL that is generated by smartGWT to make this call is:
All this request is doing is sending names of DataSources to download, it isn't sending actual data. The only response the server can make from this request is the serialized forms of the named DataSources, which are defined securely on the server. Could you tell us what exactly the perceived vulnerability is?
This is not a security vulnerability and we do not plan any changes in this area. If you believe there is a vulnerability here, please provide a runnable sample of an exploit that is made possible because DataSource names are not encoded.
I am assuming the server code is validating the URL before it gets converted to an RMI call.
I Agree that it is not processing certain unacceptable values, but importantly the string should also disallow these characters:
< > -' "/ \ ( ) @ * to prevent script execution.
?? This could only happen if the server were bouncing that encoded script back to the client for evaluation, which it will not do:
The only response the server can make from this request is the serialized forms of the named DataSources, which are defined securely on the server
If you actually try to browse to the link you are suggesting is an exploit, you will see that the server just complains that you haven't provided a proper dataSource parameter.
Obviously you are not replying to my query on this. However, we do have an issue and it be resolve at the framework level or at my level. Would you say running my criterias through an Htmlencoder will work?
I still think it may be easier on your side since you control the code. Another word if you add an overloaded function to encode the data that should takes care of everything.
Ah, so the problem is specifically the error response for bad DataSource names. Please be more clear in the future as you originally reported this as some kind of issue with URL encoding and/or with how the framework loads DataSource (which is not a valid issue).
To prevent this, you can add error handling code to DataSourceLoader that does not send back a friendly response in the case of a missing DataSource. However we have just changed the framework to deal with this automatically, and the change will be present in the next nightly build.
Comment