Stripes

NPE decrypting null value with @Validate(encrypted=true)

Details

Description

From the users mailing list...

Hi Christian,

I guess the value of the field was null when it's rendered, wasn't it?
It seems that encrypted field must have a non-null value when it is
rendered.

In my last project, I removed the field when the value is null to
workaround the issue.

<c:if test="${!empty actionBean.user.id}">
<stripes:hidden name="user.id" />
</c:if>

–
IMHO, it would be nice if null value is encrypted in the same way as
normal value because I often use the same form for both editing an
existing instance and creating a new instance (as most of you, I suppose).
Any thoughts?

Regards,
Iwao

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ryan Stuart added a comment - 06/Mar/08 12:51 AM

I had a quick look at the issue and the only potential for a NPE i could find was in DefaultActionBeanPropertyBinder. If I am correct and it is possible that value can be null on line 730, then this patch should fix the problem.

Show
Ryan Stuart added a comment - 06/Mar/08 12:51 AM I had a quick look at the issue and the only potential for a NPE i could find was in DefaultActionBeanPropertyBinder. If I am correct and it is possible that value can be null on line 730, then this patch should fix the problem.
Hide
Permalink
Ben Gunter added a comment - 26/Mar/08 10:11 AM

I believe this is fixed. A null input to encrypt() is now encrypted as "", which means that decryption will work even for a null value. Since the Stripes binding engine treats null and "" equivalently, this should not cause problems. checkHashCode() also checks the length of the input array to ensure it is at least as long as the hash code, just to be safe.

Show
Ben Gunter added a comment - 26/Mar/08 10:11 AM I believe this is fixed. A null input to encrypt() is now encrypted as "", which means that decryption will work even for a null value. Since the Stripes binding engine treats null and "" equivalently, this should not cause problems. checkHashCode() also checks the length of the input array to ensure it is at least as long as the hash code, just to be safe.
Hide
Permalink
Frederic Daoud added a comment - 15/Feb/09 8:44 AM

I think empty strings, "", should also be encrypted as empty strings so that they are treated as null by Stripes. By this I mean that for example <s:option value=""> should be encrypted as an empty string. You might want to do this for a first option in a select box that displays "Please select..." but is not a valid option for a required parameter.

Right now the workaround is to use e.g. a plain option tag, <option value="">, but I still think that encryption should be consistent for empty strings.

Show
Frederic Daoud added a comment - 15/Feb/09 8:44 AM I think empty strings, "", should also be encrypted as empty strings so that they are treated as null by Stripes. By this I mean that for example <s:option value=""> should be encrypted as an empty string. You might want to do this for a first option in a select box that displays "Please select..." but is not a valid option for a required parameter. Right now the workaround is to use e.g. a plain option tag, <option value="">, but I still think that encryption should be consistent for empty strings.
Hide
Permalink
Frederic Daoud added a comment - 15/Feb/09 10:26 AM

I've narrowed it down. What's happening is that with <s:option value="">, the empty string "" gets encrypted. However, upon submitting that value, it gets decrypted as "" and also set as "", instead of being considered as null like a plain empty string. So a required=true property gets set as "", which I think is not the expected behavior.

I'm not sure if this is an issue with encryption or with parameter binding (why does "" gets set in this case instead of being considered as null?)

Thoughts, anyone?

Show
Frederic Daoud added a comment - 15/Feb/09 10:26 AM I've narrowed it down. What's happening is that with <s:option value="">, the empty string "" gets encrypted. However, upon submitting that value, it gets decrypted as "" and also set as "", instead of being considered as null like a plain empty string. So a required=true property gets set as "", which I think is not the expected behavior. I'm not sure if this is an issue with encryption or with parameter binding (why does "" gets set in this case instead of being considered as null?) Thoughts, anyone?
Hide
Permalink
Frederic Daoud added a comment - 15/Feb/09 12:40 PM

Turned out to be an easy fix - decrypt the value first, then check for empty string "".
Fixed in build 1042 (trunk) and 1043 (1.5.x)

Show
Frederic Daoud added a comment - 15/Feb/09 12:40 PM Turned out to be an easy fix - decrypt the value first, then check for empty string "". Fixed in build 1042 (trunk) and 1043 (1.5.x)

People

Vote (0)
Watch (0)

Dates

  • Created:
    03/Mar/08 10:30 AM
    Updated:
    04/Jan/11 3:15 PM
    Resolved:
    15/Feb/09 12:40 PM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for Stripes Framework. Try JIRA - bug tracking software for your team.