Behavior of PasswordField

Flow
1

Reading Client Side Encryption reminded me of an issue we had in Vaadin 7:

There, the customer really didn’t like that the PasswordField valueChanged event that was sent to the server also contained the password in the response.

We tried to explain that everything was protected with https, but to no avail.
In the end, in the valueChanged event handler we had to take a copy of the field value and set the field to a random value.

According to Vaadin Support at the time, this was fixed in Vaadin8, but I never investigated what that fix actually was. Based on how our code works in Vaadin24, it seems to be really special.

Our Vaadin24 code does the same as before; On valueChanged event on the server-side we set the PasswordField to a random value, but now the client-side is not updated. When I click on the eye, it shows the original value. Based on that I assume:

  • If you set a value in the field when it is created, this value is sent to the client
  • After that, the value is never (?) sent to the client, even if you change it on the server side

@vaadin, is this correct?
If so, it should really be mentioned in the documentation.
Can this mechanism be (ab)used for other field types?

2

Cannot reproduce. The value shown in the component is changed for me when I run passwordField.setValue("update");.

The one generic change there might be between Vaadin 7 and Vaadin 10+ is slightly better change tracking which means that when receiving a value from the client, the server “knows” that the client already knows that value so it doesn’t have to send it back to the client in the response.

3

You’re right. Made a small testcase to verify.
It is still happening in the main app though, so I’ll have to dig through the layers to find out why.

Setting a breakpoint on PasswordField.setValue I see that it is actually called 3 times; The last resetting it back to the original value… Next to find out why there are 3 calls… :thinking:

4

I now think I have the cause. The problem is in Binder:

        private BindingValidationStatus<TARGET> writeFieldValue(BEAN bean) {
            assert bean != null;

            return execute(() -> {
                Result<TARGET> result = doConversion();
                if (!isReadOnly()) {
                    result.ifOk(value -> {
                        setter.accept(bean, value);
                        if (convertBackToPresentation && value != null) {
                            FIELDVALUE converted = convertToFieldType(value);
                            if (!Objects.equals(field.getValue(), converted)) {
                                convertedBack = true;
                                getField().setValue(converted);
                            }
                        }
                    });
                }
                return toValidationStatus(result);
            });
        }

User fills in “foo” in the field. This block is called.
In setter.accept, I change the value to “bar”
And in if(convertBackToPresentation.. vaadin calls getField().setValue(“foo”)…

This “convertBackToPresentation” is something that has annoyed me before; It makes no sense to me that displaying PI with two decimals also immediately writes back “3.14”

Looking at it now; I see that we can control this with Binding.setConvertBackToPresentation !!
Doc says this is new since “Version 6”, whatever that means.

Using setConvertBackToPresentation(false) on all our bindings seems to solve everything :grinning:

5

Flow version 6 corresponds to Vaadin version 19 so it’s been there for a while…

7

I’ve been fighting against Vaadin’s writeback since we started the migration, so at fist I was surprised that I had not discovered binding.setConvertBackToPresentation.

Looking at my Binder hack, I see that it does not help with Binder.setBean.
That method calls Binding.initFieldValue(bean, writeBackChangedValues=>true)
So, here it doesn’t use the binding.convertBackToPresentation config.

I don’t understand when writeback has any value at all, but obviously Vaadin had an internal need to skip it, introduced this parameter, and set it to a hard-coded “true”.
That line is 7 years old, so at that point the configuration didn’t exist.

Maybe that is a bug?

Should this:

public void setBean(BEAN bean) {
    ...
    getBindings().forEach(b -> b.initFieldValue(bean, true));

be

public void setBean(BEAN bean) {
    ...
    getBindings().forEach(b -> b.initFieldValue(bean, b.isConvertBackToPresentation()));

?

8

This code line is 7 ears ago. The isConvertBackToPresentation was added 4 years ago. It was done originally in Vaadin 8 by me, and then forward ported to Flow. I do not recall why I did not do this in the original version, the Binder is the same in Vaadin 8 and Flow for 98%.