Fabien MARSAUD created DELTASPIKE-768:
-----------------------------------------
Summary: GET request parameter type discrepancy silently discarded
with JSF
Key: DELTASPIKE-768
URL: https://issues.apache.org/jira/browse/DELTASPIKE-768
Project: DeltaSpike
Issue Type: Bug
Components: JSF-Module
Affects Versions: 1.0.3
Environment: Glassfish 3.1.2.2, JSF 2.1.28, Weld 1.1.14, Richfaces,
Rewrite
Reporter: Fabien MARSAUD
Priority: Minor
I have a request scoped managed bean which receives paypal IPN notifications.
IPNs contain a shared "secret" String parameter transferred as a http GET param.
I had a correct setSecret(String) on my backing bean, but because of a bad 5
year-old copy/paste, I had the wrong return type on getSecret(). It was never
noticed because the *getter* was never called anywhere, and with Seam we used
until our previous release , "secret" was *set* without complaining anyway.
On the page: {code}
<f:metadata>
<f:viewParam name="secret" value="#{orderPaypalIPN.secret}" />
</f:metadata>{code}
In the code:{code}
@Named("orderPaypalIPN")
@RequestScoped
public class OrderPaypalIPNHandler {
private String secret;
public Long getSecret() { //***TYPO: LONG INSTEAD OF STRING***
return null; //security reason
}
public void setSecret(String secret) {
this.secret = secret;
}
{code}
So, when we were using Seam, "secret" was correctly set, then used by the rest
of the code. When we started using DeltaSpike instead, "secret" was not set
anymore (even though the issue was with the getter, not the setter). I'm OK
with it (more strict, better), except that the get/set discrepancy is not
logged. I think it should be.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
