[
https://issues.apache.org/jira/browse/DELTASPIKE-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabien MARSAUD updated DELTASPIKE-768:
--------------------------------------
Description:
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;
//getter needed by JSF2
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.
was:
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.
> GET request parameter silently discarded upon type discrepancy 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
> Labels: jsf, parameter, request
>
> 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;
> //getter needed by JSF2
> 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)
