flow
flow copied to clipboard
vaadin
HasUrlParameter<Long> doesn't accept all longs
Description of the bug
Vaadin Flow seems to use ^[+-]?[0-8]?[0-9]{1,18}$ to detect whether a string contains a long value.
This causes probllems when random numbers are used as url parameters for some reason. For example using random number as temporary password or using database id's as url parameters in a situation where the ids happen to be random signed 64bit numbers.
Attempting to navigate to an url with too small or to large value causes "Could not navigate to ..."
Would it hurt to change the regex to ^[+-]?[0-9]{1,19}$ ? Then it would accept all longs, but also accept some values that can't be converted to long.
Or use this kind of regex to match long values more precisely (also accepts leading zeroes):
^(0*(([0-8]?[0-9]{1,18})|(9[0-1][0-9]{17})|(92[0-1][0-9]{16})|(922[0-2][0-9]{15})|(9223[0-2][0-9]{14})|(92233[0-6][0-9]{13})|(922337[0-1][0-9]{12})|(92233720[0-2][0-9]{10})|(922337203[0-5][0-9]{9})|(9223372036[0-7][0-9]{8})|(92233720368[0-4][0-9]{7})|(922337203685[0-3][0-9]{6})|(9223372036854[0-6][0-9]{5})|(92233720368547[0-6][0-9]{4})|(922337203685477[0-4][0-9]{3})|(9223372036854775[0-7][0-9]{2})|(922337203685477580[0-7]))|(-0*(([0-8]?[0-9]{1,18})|(9[0-1][0-9]{17})|(92[0-1][0-9]{16})|(922[0-2][0-9]{15})|(9223[0-2][0-9]{14})|(92233[0-6][0-9]{13})|(922337[0-1][0-9]{12})|(92233720[0-2][0-9]{10})|(922337203[0-5][0-9]{9})|(9223372036[0-7][0-9]{8})|(92233720368[0-4][0-9]{7})|(922337203685[0-3][0-9]{6})|(9223372036854[0-6][0-9]{5})|(92233720368547[0-6][0-9]{4})|(922337203685477[0-4][0-9]{3})|(9223372036854775[0-7][0-9]{2})|(922337203685477580[0-8]))))$
(Yes, I was lazy and constructed the regex from a negative and positive part. It guess I could be shorter.)
Expected behavior
All valid long values should be accepted.
Minimal reproducible example
Download a vaadin starter package, add implements HasUrlParameter<Long> and add setParameter method. Try adding -9223372036854775808 to the url.
Versions
Vaadin 23.2.3 Flow 23.2.3 Java 17
You can also use HasUrlParameter<String> and apply your regex on the string provided in setParameter as workaround.
Seems to me like your suggestion makes lots of sense. Long.MAX_VALUE is 9223372036854775807 which doesn't match that pattern along with roughly 10% of the whole value space of signed 64-bit integers.
I don't see any big reason for having a more complex regular expression just to definitely exclude some potentially invalid values as long as we also ensure that the resulting NumberFormatException is handled gracefully.
