[#STS-521] NPE decrypting null value with @Validate(encrypted=true)

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:

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

Change by Ben Gunter - 03/Mar/08 10:32 AM
Field	Original Value	New Value
Assignee		Ben Gunter [ bengunter ]

[ Permlink | « Hide ]

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.

Change by Ryan Stuart - 06/Mar/08 12:51 AM
Attachment		stripes-STS-521.patch [ 10232 ]

[ Permlink | « Hide ]

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.

Change by Ben Gunter - 26/Mar/08 10:11 AM
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Resolved [ 5 ]

[ Permlink | « Hide ]

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.

Change by Frederic Daoud - 15/Feb/09 08:44 AM
Status	Resolved [ 5 ]	Reopened [ 4 ]
Resolution	Fixed [ 1 ]

[ Permlink | « Hide ]

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?

[ Permlink | « Hide ]

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)

Change by Frederic Daoud - 15/Feb/09 12:40 PM
Resolution		Fixed [ 1 ]
Fix Version/s	Release 1.5 [ 10043 ]
Fix Version/s		Release 1.6 [ 10090 ]
Fix Version/s		Release 1.5.1 [ 10100 ]
Status	Reopened [ 4 ]	Resolved [ 5 ]