New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Add row limit to DataCommunicator row data requests #12415
Conversation
* Add row limit to DataCommunicator row data requests * Add missing constant * Add unit test * Add test for extending Grid * Fixed test
* Improve thread safety (#12395) See: https://vaadin.com/forum/thread/17522264/concurrentmodificationexception-in-vaadin-shared-on-karaf-4-2-x * Fix incompatible selenium version in test module. (#12397) * Fixed a dependency version in a karaf test module. (#12399) * Checkstyle tweaks to DateField widgets. (#12400) - Added and updated JavaDocs. - Updated comments. - Updated to use non-deprecated method calls. - Removed unnecessary warning suppressions. - Suppressed warnings for unavoidable deprecation. * fix: set Vaadin session attribute using lock in reinitializeSession (#12401) * Cherry picked unit test from Flow See vaadin/flow#11538 * Fix missing import * Cherry pick fix from Flow * deprecate vaadin-snasphots repo (#12405) * deprecate vaadin-snasphots repo * Update chrome version to 93 * add more screenshots * fix: Add MPR UI id request parameter (#12412) * fix: Add MPR UI id request parameter Related-to vaadin/multiplatform-runtime#85 * test: Remove redundant non-empty param test * test: Remove leftovers * fix: Init window.mprUiId earlier than window.vaadin * Add missing '=' * Update links shown by license checker (#12402) vaadin.com/pro does no longer have the info * fix: Add row limit to DataCommunicator row data requests (#12415) * Add row limit to DataCommunicator row data requests * Add missing constant * Add unit test * Add test for extending Grid * Fixed test Co-authored-by: Tatu Lund <tatu@vaadin.com> Co-authored-by: Anna Koskinen <Ansku@users.noreply.github.com> Co-authored-by: Zhe Sun <31067185+ZheSun88@users.noreply.github.com> Co-authored-by: Mikhail Shabarov <61410877+mshabarov@users.noreply.github.com>
|
Same issue here with TwinColSelect component. We do need to use more than 500 rows, is there anyway to override this? |
@gbougiakas yes, check the GridTest.java in this very pull request |
Thanks for the reply, I checked GridTest.java and Grid appears to have a constructor that takes a DataCommunicator as an argument. TwinColSelect does not have such a constructor. I need to override the setItems method but it's not obvious to me of what I should do in there. Can you help me? |
|
Create a new DataCommunicator subclass like in GridTest. Override |
|
With TwinColSelect it looks like this |
Thank you both for the swift replies. Here is my custom TwinColSelect ` } ` Unfortunately now I get a NullPointerException upon calling the constructor of the TwinColSelectWithCustomRowLimit. Any further help is much appreciated. |
|
Seems like the the overriden getDataCommunicator() is called before the constructor for some reason, hence the custom DataCommunicator instance is null. |
|
I, see some components are trickier to extend. I opened PR for easier configurability |
Thanks for the swift response. I will remain at 8.14.0 until there is an easy way to bypass this for the components we need more than 500 rows in our dataset. Regards |
|
As I've just commented in #12428, this limit to 500 items in ListSelect, TwinColSelect, ComboBox broke potentially a lot of code without proper warning that a 8.14.1 made a breaking change to previously legitimate and working code. We have potentially many places were such crash may happen with backend data providers of unknown size. Could the CVE be solved with proper way, without breaking code working fine for many years ? |
No, that is not the good approach in this case. We want to follow the same principle here as we have for XSS for example. By default our components do not allow HTML content (say Label, tooltip etc.), and you need to specifically with the API define that HTML content is allowed. I.e. then application developer takes the responsibility to take care that HTML content does not possess harm. Here we are working analogous way. By default framework limits the size, but you can override it. See the #12466, we will introduce API take makes the override less hacky. |
|
I don't see relation to XSS here. And even if there is such limit (which I still thing is a bad idea), it needs to be properly documented in all the possible places. |
@mletenay That is a valid argument, I improved the release note |
|
@TatuLund Thanks for the release notes adjustment, but again I'm not sure this is sufficient. |
|
@mletenay We will update some documentation when #12466 is released. After that the following will be possible |
|
We also ran in this problem and I understand the point of @mletenay very well. We and our customers have some ComboBos with a lot of entries and we disabled pagination because our users did not see easily how to go down to the next page (no real scrollbar, buttons nearly unvisible). However even with pagination there would be the problem if I understood #12428 correctly. However I do not see why it was not fixed without breaking the behavior at least for ListDataProvider (or maybe other InMemoryDataProvider). In a ListDataProvider the server knows exactly how many Items there are at most and could set this number of items automatically. When do you plan to release the fix to specify the allowed rowes? |
|
Vaadin 8.14.3 was released today with the API to override the limit if so needed. |
|
I'm sorry but this fix is stupid. It's not fixing the core problem of the attack but makes life for developers harder. So now we have to estimate a number which could be possible. And if the number is big enough we reenabled the weakness to be attackable. |
|
We have combo boxes in our application, where we do not really have the size under control. |
No description provided.