[JBoss JIRA] (RF-13208) Push: error "not well-formed" appears in browser console in Firefox - make messages a valid XML
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13208?page=com.atlassian.jira.plugin.s... ]
Juraj Húska closed RF-13208.
----------------------------
Verified also for 5.0.0.Alpha3. Closing.
> Push: error "not well-formed" appears in browser console in Firefox - make messages a valid XML
> -----------------------------------------------------------------------------------------------
>
> Key: RF-13208
> URL: https://issues.jboss.org/browse/RF-13208
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.4
> Environment: RichFaces 4.3.4.Final
> Metamer 4.3.4.20130919-Final
> Mojarra 2.1.19
> EAP 6.1.1
> OpenJDK Runtime Environment 1.7.0_40-mockbuild_2013_09_19_20_10-b00 @ Linux
> Firefox 24.0 @ Linux x86_64
> Reporter: Pavol Pitonak
> Assignee: Lukáš Fryč
> Fix For: 4.3.5, 5.0.0.Alpha3
>
> Attachments: firefox_console.png
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> # deploy Metamer and open http://127.0.0.1:8080/metamer/faces/components/a4jPush/twoPush.xhtml
> # open browser console
> # click "Push 2!" button
> result:
> * browser console contains "not well-formed" JavaScript error (see screenshot)
> * when you click on the error, you can see something like this:
> {quote}
> <"topic":"jmsSampleAddress2","data":"day: 23, month: 9, time: 11:01:12.829","number":0>
> {quote}
> * component seems to work fine despite this error
> * I couldn't see this error in Chrome 29
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13478) VDL documentation typos
by Vasil Lukach (JIRA)
Vasil Lukach created RF-13478:
---------------------------------
Summary: VDL documentation typos
Key: RF-13478
URL: https://issues.jboss.org/browse/RF-13478
Project: RichFaces
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: doc
Affects Versions: 4.3.4, 4.3.3
Reporter: Vasil Lukach
Priority: Trivial
RichFaces VDL documentation typos:
1) rich:fileUpload
- uploadLabel attribute : Add -> Upload
- execute attribute (proposal): remove "Some components make use of additional keywords"
2) a4j:mediaOutput
element attribute: imj -> img
3) accordion: epand -> expand
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13239) Popup panel: CSS class rf-pp-hdr contains invalid property repeat-x
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13239?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak reopened RF-13239:
--------------------------------
Image URL is not rendered correctly in RF 5:
{code}
*.rf-pp-hdr {
background: "#BED6F8" "url()" repeat-x scroll top left;
... }
{code}
In RF 4.3, this warning is present in browser console (notice quotes):
{code}
Invalid CSS property value: "#BED6F8" "url(/metamer/faces/rfRes/gradientA.png?v=4.3.5-SNAPSHOT&db=eAFjZJBjZDBiZBBh!P!p-3!G!!uu!WBgAgA7vgfe&ln=org.richfaces.images)" repeat-x scroll top left
{code}
Probably this (or something similar) should be used in popupPanel.ecss:
{code}
background: "#{richSkin.headerBackgroundColor} #{richSkin.imageUrl('gradientA.png')} repeat-x scroll top left";
{code}
> Popup panel: CSS class rf-pp-hdr contains invalid property repeat-x
> -------------------------------------------------------------------
>
> Key: RF-13239
> URL: https://issues.jboss.org/browse/RF-13239
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 5.0.0.Alpha1
> Environment: RichFaces 5.0.0-SNAPSHOT
> Reporter: Pavol Pitonak
> Assignee: Brian Leathem
> Priority: Minor
> Labels: needs-qe
> Fix For: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> # deploy Metamer and open http://localhost:8080/metamer/faces/components/richPopupPanel/simple.xhtml
> # check browser console
> result:
> * Invalid CSS property name: repeat-x (in popupPanel.ecss, line 40)
> possible solution:
> * replace
> {code}
> .rf-pp-hdr {
> background: url(...);
> repeat-x: top left #BED6F8;
> ...
> }
> {code}
> * with
> {code}
> .rf-pp-hdr {
> background: url(...) repeat-x top left #BED6F8;
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13198) ITAutoRegisteredPushServlet fails with - Async is not supported for this request on WildFly80
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13198?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč reassigned RF-13198:
-------------------------------
Assignee: Lukáš Fryč
> ITAutoRegisteredPushServlet fails with - Async is not supported for this request on WildFly80
> ---------------------------------------------------------------------------------------------
>
> Key: RF-13198
> URL: https://issues.jboss.org/browse/RF-13198
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha1
> Environment: WildFly8.0.0.alpha4
> JSF 2.2
> Reporter: Juraj Húska
> Assignee: Lukáš Fryč
> Labels: jsf22
> Fix For: 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> When loading the page which is generated by {{ITAutoRegisteredPushServlet}}, deployed on Wildfly 8.0.0 an {{IllegalArqumentEception}} is thrown by WildFly Undertow web server:
> {code}
> 11:02:19,931 ERROR [io.undertow.request] (default task-13) Servlet request failed HttpServerExchange{ GET /push/__richfaces_push}: java.lang.IllegalStateException: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async
> at io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:876) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.atmosphere.cpr.AtmosphereRequest.startAsync(AtmosphereRequest.java:565) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.container.Servlet30CometSupport.suspend(Servlet30CometSupport.java:137) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.container.Servlet30CometSupport.service(Servlet30CometSupport.java:103) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1370) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:293) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:279) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.jboss.arquillian.warp.impl.server.execution.HttpRequestProcessor.processHttpRequest(HttpRequestProcessor.java:73) [arquillian-warp.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-core.jar:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) [arquillian-core.jar:]
> at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterWarp(WarpFilter.java:144) [arquillian-warp.jar:]
> at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilterHttp(WarpFilter.java:117) [arquillian-warp.jar:]
> at org.jboss.arquillian.warp.impl.server.execution.WarpFilter.doFilter(WarpFilter.java:90) [arquillian-warp.jar:]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
> Note that it is probably not connected with JSF 2.2, as the same page works correctly with *GlassFish 4*. It works with *JBoss AS 7.1.Final* as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13168) 3rd party JSF component disappears on RichFaces ajax refresh
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-13168?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč reassigned RF-13168:
-------------------------------
Assignee: Lukáš Fryč
> 3rd party JSF component disappears on RichFaces ajax refresh
> ------------------------------------------------------------
>
> Key: RF-13168
> URL: https://issues.jboss.org/browse/RF-13168
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility, component-a4j-core
> Reporter: Frank Langelage
> Assignee: Lukáš Fryč
> Labels: interop, jsf22
> Fix For: 5.0.0.Alpha3
>
> Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13358) rich:panelMenuGroup allowing actions executions even if originally disabled
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13358?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13358.
--------------------------------
Resolution: Done
> rich:panelMenuGroup allowing actions executions even if originally disabled
> ---------------------------------------------------------------------------
>
> Key: RF-13358
> URL: https://issues.jboss.org/browse/RF-13358
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.4
> Environment: Linux, AS 7.1.1 Brontes, FF 25 with FireBug addOn
> Reporter: Pavel Slegr
> Assignee: Brian Leathem
> Priority: Critical
> Labels: needs-qe
> Fix For: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> related to https://issues.jboss.org/browse/RF-12813
> This can be possibly a security hole, as the second component piece is discovered to allow tampering actions through JS.
> I suggest to try out on other components as well !!!
> with following example
> {code}
> {
> <rich:panelMenuGroup id="group4" label="Group 4" expanded="false">
> <rich:panelMenuItem id="item41" label="Item 4.1" />
> <rich:panelMenuItem id="item42" label="Item 4.2" disabled="true" />
> <rich:panelMenuGroup id="group43" label="Group 4.1" disabled="true">
> <rich:panelMenuItem id="item431" label="Item 4.1.1" />
> </rich:panelMenuGroup>
> </rich:panelMenuGroup>
> }
> {code}
> the group43 element is intended to be disabled and thus not allowing any actions execution on it
> Once tampered with
> {code}
> {
> new RichFaces.ui.PanelMenuGroup("f:group43",{"collapseEvent":"click","unselectable":false,"selectable":false,"name":"group43","ajax":{"incId":"1"} ,"stylePrefix":"rf\u002Dpm\u002Dgr","expanded":false,"expandEvent":"click","disabled":false,"mode":"client"} )
> }
> {code}
> It is possible to expand the group and execute further actions on its children elements
> NOTE: to verify this in RF 4.5 the JS function is: _new RichFaces.rf4.ui....._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13358) rich:panelMenuGroup allowing actions executions even if originally disabled
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13358?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13358:
------------------------------------
I've updated the panelMenuGroup renderer to prevent _expansion_ when in _ajax mode_.
Note:
* One will still be able to override the menuGroup expansion with client-side javascript when the panelMenuGroup is in _client mode_. This is because the menu items are rendered to the client and there is no way to block the expansion on the server. We can open a new jira issue to discuss whether menu items should be rendered for menuGroups in _client mode_. I have demonstrated this in an updated test.
* The menuItems themselves will not execute on the server when clicked if they have a disabled parent panelMenuGroup or panelMenu (client mode or otherwise).
> rich:panelMenuGroup allowing actions executions even if originally disabled
> ---------------------------------------------------------------------------
>
> Key: RF-13358
> URL: https://issues.jboss.org/browse/RF-13358
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.4
> Environment: Linux, AS 7.1.1 Brontes, FF 25 with FireBug addOn
> Reporter: Pavel Slegr
> Assignee: Brian Leathem
> Priority: Critical
> Labels: needs-qe
> Fix For: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> related to https://issues.jboss.org/browse/RF-12813
> This can be possibly a security hole, as the second component piece is discovered to allow tampering actions through JS.
> I suggest to try out on other components as well !!!
> with following example
> {code}
> {
> <rich:panelMenuGroup id="group4" label="Group 4" expanded="false">
> <rich:panelMenuItem id="item41" label="Item 4.1" />
> <rich:panelMenuItem id="item42" label="Item 4.2" disabled="true" />
> <rich:panelMenuGroup id="group43" label="Group 4.1" disabled="true">
> <rich:panelMenuItem id="item431" label="Item 4.1.1" />
> </rich:panelMenuGroup>
> </rich:panelMenuGroup>
> }
> {code}
> the group43 element is intended to be disabled and thus not allowing any actions execution on it
> Once tampered with
> {code}
> {
> new RichFaces.ui.PanelMenuGroup("f:group43",{"collapseEvent":"click","unselectable":false,"selectable":false,"name":"group43","ajax":{"incId":"1"} ,"stylePrefix":"rf\u002Dpm\u002Dgr","expanded":false,"expandEvent":"click","disabled":false,"mode":"client"} )
> }
> {code}
> It is possible to expand the group and execute further actions on its children elements
> NOTE: to verify this in RF 4.5 the JS function is: _new RichFaces.rf4.ui....._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (RF-13358) rich:panelMenuGroup allowing actions executions even if originally disabled
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13358?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13358:
------------------------------------
{quote}
Explanation:
For example test test_disabled_menu_group, here, is trying to:
click on the group to collapse it
{quote}
The test is in fact clicking on a menu item of an already expanded menu group and trying to execute the menuItem
{quote}
verifying whether an ajax request changed the state of the bean bound to the group action param.
However, there is no Ajax request made, and at the same time the group is collapsed even when it is disabled (tampered with the script executed after the page load). Therefore, test wrongly expect that the group is still disabled.
{quote}
doesn't _guardAjax_ ensure that an ajax request takes place?
{quote}
It is weird, because in one hand the group is not making Ajax request when clicked (I guess because of some client check), and on the other hand it is expanded/collapsed.
{quote}
It's the menuItem that is supposed to make the ajax request when clicked, not the menuItem.
----
I believe see now what's going on. The fix I put in was to prevent execution of menuItems, and what you (QA) are checking is if the group can be expanded. I'll investigate now if that makes sense.
> rich:panelMenuGroup allowing actions executions even if originally disabled
> ---------------------------------------------------------------------------
>
> Key: RF-13358
> URL: https://issues.jboss.org/browse/RF-13358
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-menu
> Affects Versions: 4.3.4
> Environment: Linux, AS 7.1.1 Brontes, FF 25 with FireBug addOn
> Reporter: Pavel Slegr
> Assignee: Brian Leathem
> Priority: Critical
> Labels: needs-qe
> Fix For: 4.3.5, 4.5.0.Alpha2, 5.0.0.Alpha3
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> related to https://issues.jboss.org/browse/RF-12813
> This can be possibly a security hole, as the second component piece is discovered to allow tampering actions through JS.
> I suggest to try out on other components as well !!!
> with following example
> {code}
> {
> <rich:panelMenuGroup id="group4" label="Group 4" expanded="false">
> <rich:panelMenuItem id="item41" label="Item 4.1" />
> <rich:panelMenuItem id="item42" label="Item 4.2" disabled="true" />
> <rich:panelMenuGroup id="group43" label="Group 4.1" disabled="true">
> <rich:panelMenuItem id="item431" label="Item 4.1.1" />
> </rich:panelMenuGroup>
> </rich:panelMenuGroup>
> }
> {code}
> the group43 element is intended to be disabled and thus not allowing any actions execution on it
> Once tampered with
> {code}
> {
> new RichFaces.ui.PanelMenuGroup("f:group43",{"collapseEvent":"click","unselectable":false,"selectable":false,"name":"group43","ajax":{"incId":"1"} ,"stylePrefix":"rf\u002Dpm\u002Dgr","expanded":false,"expandEvent":"click","disabled":false,"mode":"client"} )
> }
> {code}
> It is possible to expand the group and execute further actions on its children elements
> NOTE: to verify this in RF 4.5 the JS function is: _new RichFaces.rf4.ui....._
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months