2

I have a SelectOneMenu driven by a List, each of which contains an object value and a string label, along with a converter. All fairly standard. I initially got the Validation Error: Value is not valid error because of a typo in the equals method, but a quick search on how to fix that brings up another question:

Am I right in my understanding that, in this scenario, what happens is:

  1. An item is selected in the menu.
  2. This sends a string value to the server.
  3. The converter is used to convert the string value to an object.
  4. JSF checks that the object exists in the list of items.
  5. The setter method is called passing the object.

If so, then can I disable step 4? My converter will throw a ConverterException if the value is not valid, so for me this second list traversal is completely unnecessary.

Cheers,

Barney

Community
  • 1
  • 1
Barney
  • 2,786
  • 2
  • 32
  • 34

1 Answers1

0

This is by design. It's one of the standard website attack preventions. You can't turn it off.

Just put the bean in view scope (so that it won't be refetched on every request, for the case that), or look for a less secure MVC framework if it bothers you.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 3
    "You can't turn it off": Yeah - that's what I feared. "...or look for a less secure MVC framework...": Sorry, I completely disagree with the implication that making this validation optional would make the framework less secure. I already have two opportunities to validate the data (custom validators and the converter) before it gets to checking the list. I can see the usefulness of this as a default check if there are no other checks present, but I still see no reason to force me to do completely redundant validation. – Barney Jan 22 '11 at 04:34
  • To recreate the state of the view in the managed bean we need the very same form parameters that are being "validated" and that JSF prevents from make it to the managed bean. Doesn't look a clever design to me. – Agustí Sánchez Aug 19 '14 at 16:26