History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: STS-521
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Ben Gunter
Reporter: Ben Gunter
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Stripes

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

Created: 03/Mar/08 10:30 AM   Updated: 15/Feb/09 12:40 PM
Component/s: Validation, Formatting
Affects Version/s: None
Fix Version/s: Release 1.6, Release 1.5.1

File Attachments: 1. Text File stripes-STS-521.patch (0.7 kb)



 Description  « Hide
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

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Ryan Stuart - 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.

Ben Gunter - 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.

Frederic Daoud - 15/Feb/09 08: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.

Frederic Daoud - 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?

Frederic Daoud - 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)