[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298923#comment-16298923
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 10:36 PM:


After looking at this today I think we need to decide the following.

1) Template can not be loaded from /resources by default or the value specified 
by javax.faces.WEBAPP_RESOURCES_DIRECTORY.

Is this the new intended behavior? Am I not understanding something here?




was (Author: paul.nicolucci):
So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the templates in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

1) Template can not be loaded from /resources by default or the value specified 
by javax.faces.WEBAPP_RESOURCES_DIRECTORY.

Is this the new intended behavior? Am I not understanding something here?



> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298861#comment-16298861
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 10:35 PM:


I've tested and even directly specifying the template location without using 
the bean in the sample application it still does not work:

template="/WEB-INF/templates/basicTemplate.xhtml" (works) vs 
template="/resources/templates/basicTemplate.xhtml" (does not work):


{code:java}
java.io.FileNotFoundException: /resources/templates/basicTemplate.xhtml Not 
Found in ExternalContext as a Resource
at 
org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:300)
at [internal classes]
{code}



was (Author: paul.nicolucci):
I've tested and even directly specifying the template location without using 
the bean in the sample application it still does not work:

template="/WEB-INF/templates/basicTemplate.xhtml" (works) vs 
template="/WEB-INF/resources/templates/basicTemplate.xhtml" (does not work):


{code:java}
java.io.FileNotFoundException: /WEB-INF/resources/templates/basicTemplate.xhtml 
Not Found in ExternalContext as a Resource
at 
org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:300)
at [internal classes]
{code}


> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298708#comment-16298708
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 10:34 PM:


I'm not sure I understand the reasoning here as to why this should not work. At 
the core of the issue is if the template is in the resources/templates 
directory it can not be loaded. However if that same file is moved to the 
WEB-INF/templates directory then it works as it did in JSF 2.2. I don't see how 
the location of the template in the resources directory should not be usable in 
jsf2.3


was (Author: paul.nicolucci):
I'm not sure I understand the reasoning here as to why this should not work. At 
the core of the issue is if the template is in the WEB-INF/resources/templates 
directory it can not be loaded. However if that same file is moved to the 
WEB-INF/templates directory then it works as it did in JSF 2.2. I don't see how 
the location of the template in a directory path that contains "resources" 
should allow the template to not be usable in JSF 2.3.

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298923#comment-16298923
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 7:26 PM:
---

So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the templates in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

1) Template can not be loaded from /resources by default or the value specified 
by javax.faces.WEBAPP_RESOURCES_DIRECTORY.

Is this the new intended behavior? Am I not understanding something here?




was (Author: paul.nicolucci):
So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the templates in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

If everyone is in agreement that this is the behavior we have to introduce for 
jsf2.3 then I think we are ok.


> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298923#comment-16298923
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 7:00 PM:
---

So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the templates in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

If everyone is in agreement that this is the behavior we have to introduce for 
jsf2.3 then I think we are ok.



was (Author: paul.nicolucci):
So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the tempaltes in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

If everyone is in agreement that this is the behavior we have to introduce for 
jsf2.3 then I think we are ok.


> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298923#comment-16298923
 ] 

Paul Nicolucci commented on MYFACES-4175:
-

So looking at this a bit more closely I see what's going on here. The reason 
the application is not loading resources from WEB-INF/resources/templates but 
is from WEB-INF/templates is because the application defines the following in 
the web.xml:


{code:java}
  

javax.faces.WEBAPP_RESOURCES_DIRECTORY

WEB-INF/resources
  
{code}

If I remove the above then the tempaltes in WEB-INF/resources/templates can be 
loaded. We won't load templates from the specified directory or default 
/resources directory due to the change in RootExternalContextResourceLoader

If everyone is in agreement that this is the behavior we have to introduce for 
jsf2.3 then I think we are ok.


> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298861#comment-16298861
 ] 

Paul Nicolucci commented on MYFACES-4175:
-

I've tested and even directly specifying the template location without using 
the bean in the sample application it still does not work:

template="/WEB-INF/templates/basicTemplate.xhtml" (works) vs 
template="/WEB-INF/resources/templates/basicTemplate.xhtml" (does not work):


{code:java}
java.io.FileNotFoundException: /WEB-INF/resources/templates/basicTemplate.xhtml 
Not Found in ExternalContext as a Resource
at 
org.apache.myfaces.view.facelets.impl.DefaultFaceletFactory.resolveURL(DefaultFaceletFactory.java:300)
at [internal classes]
{code}


> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298708#comment-16298708
 ] 

Paul Nicolucci edited comment on MYFACES-4175 at 12/20/17 6:21 PM:
---

I'm not sure I understand the reasoning here as to why this should not work. At 
the core of the issue is if the template is in the WEB-INF/resources/templates 
directory it can not be loaded. However if that same file is moved to the 
WEB-INF/templates directory then it works as it did in JSF 2.2. I don't see how 
the location of the template in a directory path that contains "resources" 
should allow the template to not be usable in JSF 2.3.


was (Author: paul.nicolucci):
I'm not sure I understand the reasoning here as to why this should not work. At 
the core of the issue is if the template is in the WEB-INF/resources/templates 
directory it can not be loaded. However if that same facelet is moved to the 
WEB-INF/templates directory then it works as it did in JSF 2.2. I don't see how 
the location of the template in a directory path that contains "resources" 
should allow the template to not be usable in JSF 2.3.

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4175) template XHTML file fails to load when in /resources dir

2017-12-20 Thread Paul Nicolucci (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298708#comment-16298708
 ] 

Paul Nicolucci commented on MYFACES-4175:
-

I'm not sure I understand the reasoning here as to why this should not work. At 
the core of the issue is if the template is in the WEB-INF/resources/templates 
directory it can not be loaded. However if that same facelet is moved to the 
WEB-INF/templates directory then it works as it did in JSF 2.2. I don't see how 
the location of the template in a directory path that contains "resources" 
should allow the template to not be usable in JSF 2.3.

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server

2017-12-20 Thread Leonardo Uribe 
Hi

My mistake to suggest secureRandom as default. After doing the whole review
it
becomes clear.

In this moment with the methods moved to StateCache there is a conflict,
because through
the SPI interface (StateCacheFactory) in MYFACES-4078 you could override
the token
processing/generation, and that's not wanted by security reasons. I need to
change my
mind about instantiate StateTokenProcessor by StateCache, it doesn't work
by that reason.

I'll refactor the code to see what we can do.

regards,

Leonardo Uribe

2017-12-20 2:54 GMT-05:00 Thomas Andraschko :

> Hi,
>
> you suggested to make secureRandom as default, independent if we do this
> change or not.
> IMO "random" is enough - just sequence isn't safe enough anymore and must
> not be used.
>
> +0 for reintroduce StateTokenProcessor
> I currently don't see any benefit for another layer and i'm unsure if this
> abstraction is ever needed.
> But if you would like to refactor it, please do.
>
>
> Regards,
> Thomas
>
> 2017-12-20 2:18 GMT+01:00 Leonardo Uribe :
>
>> Hi
>>
>> secureRandom is a performance bottleneck. That's a fact. It can't be set
>> as default.
>>
>> See for example this blog:
>>
>> http://www.mattnworb.com/post/the-dangers-of-java-security-securerandom/
>>
>> "... If you don’t read the descriptions carefully enough, you might miss
>> the fact
>> that /dev/random will block when there is not enough entropy data
>> available.
>> This means that in practice, it’s possible for your calls to
>> new SecureRandom() to block for an unknown amount of time"
>>
>> About MYFACES-3779: well, we are not solving that one here, but the
>> current
>> abstraction is strong enough to support it.
>>
>> About delete StateTokenProcessor: The token can include a mac, is
>> encrypted,
>> compressed, serialized. I think each one of these steps is complex enough
>> to
>> be encapsulated in one isolated class. Maybe we need to consider that
>> StateTokenProcessor must be instantiated by StateCache, not by
>> HtmlResponseStateManager. I don't think we are over engineering here,
>> because
>> the big abstraction are the three methods that does not really change,
>> but if
>> I want to create a new StateCache, maybe I don't want to write those three
>> methods over again, right? If I'm writing a new StateCache instance, I
>> want
>> to focus on how to store the state. Please note MYFACES-4078 expose
>> StateCacheFactory/StateCache to the public since 2.3.0, so these 3 methods
>> in StateCache creates a conflict with this issue I have been working for a
>> long time.
>>
>> This issue makes me feel I'm walking in circles.
>>
>> Keep it simple, follow the facts, the old known algorithm that uses mac
>> +encryption
>> works just fine. The algorithm has been designed to keep the token very
>> small
>> (IntIntKey...), so simplify here undo a previous work in that area. This
>> is
>> a problem where we reach a dead end. Just turn back.
>>
>> But move StateTokenProcessor inside StateCache is a good idea, but a
>> default implementation that behaves like we already know is important.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>
>> 2017-12-19 16:23 GMT-05:00 Thomas Andraschko > >:
>>
>>> Yep, it's a viewstate-id or token, not view-id of course!
>>> If the current secureRandom is not perfect, we can still improve it.
>>> Also without this change discussed here, we would have set secureRandom
>>> as our default (we discussed this in the other topic), so i don't think see
>>> a problem here.
>>>
>>>
>>> I understand your point about https://issues.apache.org/jira
>>> /browse/MYFACES-3779 but quite a lot work must be done to get this
>>> working and is unsure if we will ever work on something.
>>> Also if we would work on it, i'm sure we would have to refactor much
>>> more things.
>>>
>>> Also your statement
>>> "The key point is maybe the state saving mode has something to say about
>>> how the token is processed."
>>> says that its actually one unit.
>>>
>>> We should not over-engineer something which is maybe never required.
>>> maintainability > abstraction - as it's already quite hard the follow
>>> our code in some places.
>>>
>>>
>>>
>>>
>>> 2017-12-19 21:57 GMT+01:00 Leonardo Uribe :
>>>
 Hi

 TA>> Yep, it's not a bug but a good improvement. Personally i would
 only do
 TA>> it in 2.3.

 I agree, only 2.3.

 TA>> As i already explained, i removed those classes as "sequence"
 view-id
 TA>> generator must not be used anymore.

 I'm confused about this term "view-id". It is similar to JSF viewId,
 which
 is the path of the view. Let's do some recap.

 In server side state saving we use a token. This token is composed of:

 - A session counter.
 - viewId or related hashCode.
 - (optional) a random number.

 In JSF 1.1 the full viewId path was saved with a sequence to be able to

[jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

2017-12-20 Thread Andy Gumbrecht (JIRA) 

[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298050#comment-16298050
 ] 

Andy Gumbrecht commented on MYFACES-4133:
-

Hi All, I've not taken any liberty in the patches - The applied 2.3.x revisions 
are in the patch names. These have been submitted purely to resolve the remote 
code execution issue.
We use MyFaces over at Apache TomEE - So I'm not wanting to tread on any toes 
here.
I'd just like to get your judgement on how you feel about this and if and when 
a release on the 2.1.x would occur - We've users that would like to get that 
plugged, so we're thinking about cutting an internal early access release.
Best regards, Andy.

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
> Attachments: 2.1.x-r1817658-r1817712.patch, MYFACES-4133.patch, 
> trunk-r1817658-r1817806.patch
>
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)