Block Request for Inaccessible Widgets"

From Documentation
m ((via JWB))
 
(5 intermediate revisions by 2 users not shown)
Line 6: Line 6:
  
 
= Non-existing Components are Safer than Invisible Ones =
 
= Non-existing Components are Safer than Invisible Ones =
Users can easily access inaccessible elements (such as disabled or invisible ones) by a browser developer tool. For example, a hostile user can make an invisible button visible and then click it to trigger unexpected actions. Thus, it is recommended not to create an element if it is not supposed to be accessible. For example, the first statement is safer than the second one in the following example:
+
Users can easily access inaccessible elements (such as disabled or invisible ones) with a browser developer tool. For example, a hostile user can make an invisible button visible and then click it to trigger unexpected actions. Thus, it is recommended not to create an element if it is not supposed to be accessible. For example, the first statement is safer than the second one in the following example:
  
 
<source lang="xml">
 
<source lang="xml">
Line 18: Line 18:
  
  
ZK Enterprise Edition provides a <javadoc>org.zkoss.zkmax.au.InaccessibleWidgetBlockService</javadoc> to block events sent from inaccessible widgets with a default set of rules. Because such default rules don't apply to all use cases, it is not enabled by default.
+
ZK provides the `<javadoc>org.zkoss.zkmax.au.InaccessibleWidgetBlockService</javadoc>` to block events sent from inaccessible widgets with a default set of rules. An inaccessible widget is defined as one that is either disabled, invisible, or read-only. It's important to note that these default rules may not apply to all use cases.
 +
 
 +
Before 10.0.0, the Inaccessible Widget Blocking Service is not enabled by default. Users need to enable it manually.
 +
 
 +
== Enable by Default ==
 +
{{versionSince|10.0.0}} In ZK 10.0.0 and later, this blocking service is enabled by default to enhance security.
 +
 
 +
== How to Disable ==
 +
Since this service blocks all events sent from invisible components. If you have such need, you can disable it.
 +
<source lang='xml'>
 +
<library-property>
 +
    <name>org.zkoss.zkmax.au.IWBS.disable</name>
 +
    <value>true</value>
 +
</library-property>
 +
</source>
 +
 
  
 
== Limitation ==
 
== Limitation ==
Your business class should be responsible of verifying user roles and the associated permissions. As a UI framework this feature works as a filter (helper) that blocks the general cases before your business class verifies the user permissions, which can save the cost. Please note that this service should not play the main role of determining available permissions associated to the roles.
+
This service is an additional filter to improve security but does not replace verifying roles and permissions in your business logic. Always verify access on the server side.
  
  
Line 41: Line 56:
 
* Block all events from '''disabled''' and '''invisible''' components
 
* Block all events from '''disabled''' and '''invisible''' components
 
* Block <code>onChange, onChanging, onSelect</code> of a '''read-only''' component
 
* Block <code>onChange, onChanging, onSelect</code> of a '''read-only''' component
* '''Not''' block <code>onOpen</code>
+
* '''Don't''' block <code>onOpen</code>
 
<!-- see protected static boolean shallBlockPerComponent(AuRequest request) -->
 
<!-- see protected static boolean shallBlockPerComponent(AuRequest request) -->
  
== Specify Events to Block ==
 
In many cases, you just want to block particular events, not all events. Then, you can specify a list of events in <code>zk.xml</code> below to control the behavior of <javadoc>org.zkoss.zkmax.au.InaccessibleWidgetBlockService</javadoc>. For example,
 
  
<source lang="xml">
+
== Supported Components ==
<library-property>
 
<name>org.zkoss.zkmax.au.IWBS.events</name>
 
<value>onClick,onChange,onSelect</value>
 
</library-property>
 
</source>
 
 
 
= Supported Components =
 
  
 
All invisible components are blocked.
 
All invisible components are blocked.
Line 103: Line 109:
 
| Selectbox
 
| Selectbox
 
|}
 
|}
 +
 +
== Specify Events to Block ==
 +
If you just want to block particular events, not all events. Then, you can specify a list of events in <code>zk.xml</code> like below to control the behavior of <javadoc>org.zkoss.zkmax.au.InaccessibleWidgetBlockService</javadoc>. For example,
 +
 +
<source lang="xml">
 +
<library-property>
 +
<name>org.zkoss.zkmax.au.IWBS.events</name>
 +
<value>onClick,onChange,onSelect</value>
 +
</library-property>
 +
</source>
  
 
= Implement Your Own Blocking Rules =
 
= Implement Your Own Blocking Rules =
 
If you want to block a request for inaccessible widgets for the whole application or for a particular desktop, you can implement the <javadoc>org.zkoss.zk.au.AuService</javadoc> interface to filter out unwanted requests.
 
If you want to block a request for inaccessible widgets for the whole application or for a particular desktop, you can implement the <javadoc>org.zkoss.zk.au.AuService</javadoc> interface to filter out unwanted requests.
The implementation of <code>AuService</code> is straightforward. For example, the following example blocks only <code>button</code> and <code>onClick</code>:
+
The implementation of <code>AuService</code> is straightforward. For example, the following example blocks only <code>onClick</code> of <code>Button</code>:
  
 
<source lang="java">
 
<source lang="java">
Line 118: Line 134:
 
</source>
 
</source>
  
=Version History=
 
  
{| class='wikitable' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| 8.0.3
 
| 2016/09/21
 
| Add "supported components" table
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 07:14, 18 April 2024


DocumentationZK Developer's ReferenceSecurity TipsBlock Request for Inaccessible Widgets
Block Request for Inaccessible Widgets



Non-existing Components are Safer than Invisible Ones

Users can easily access inaccessible elements (such as disabled or invisible ones) with a browser developer tool. For example, a hostile user can make an invisible button visible and then click it to trigger unexpected actions. Thus, it is recommended not to create an element if it is not supposed to be accessible. For example, the first statement is safer than the second one in the following example:

<button unless="${accessible}"/>
<button visible="${accessible}"/>

Block with InaccessibleWidgetBlockService

Since 5.0.0

  • Available for ZK:
  • http://www.zkoss.org/product/zkhttp://www.zkoss.org/whyzk/zkeeVersion ee.png


ZK provides the `InaccessibleWidgetBlockService` to block events sent from inaccessible widgets with a default set of rules. An inaccessible widget is defined as one that is either disabled, invisible, or read-only. It's important to note that these default rules may not apply to all use cases.

Before 10.0.0, the Inaccessible Widget Blocking Service is not enabled by default. Users need to enable it manually.

Enable by Default

Since 10.0.0 In ZK 10.0.0 and later, this blocking service is enabled by default to enhance security.

How to Disable

Since this service blocks all events sent from invisible components. If you have such need, you can disable it.

<library-property>
    <name>org.zkoss.zkmax.au.IWBS.disable</name>
    <value>true</value>
</library-property>


Limitation

This service is an additional filter to improve security but does not replace verifying roles and permissions in your business logic. Always verify access on the server side.


Apply the Default Blocking Service

To apply it to the whole application, just specify the following in zk.xml as follows:

<listener>
	<listener-class>org.zkoss.zkmax.au.InaccessibleWidgetBlockService$DesktopInit</listener-class>
</listener>

Then, each time a desktop is created, an instance of InaccessibleWidgetBlockService is added to the desktop to block the requests from the inaccessible widgets.


Default Blocking Rules

  • Block all events from disabled and invisible components
  • Block onChange, onChanging, onSelect of a read-only component
  • Don't block onOpen


Supported Components

All invisible components are blocked. Some components are blocked when they are disabled/read-only, as follows:

Component
Button
A
Listbox
Menuitem
Navitem
Textbox
Tree
Intbox
Spinner
Doublebox
Decimalbox
Longbox
Doublespinner
Timepicker
Timebox
Checkbox
Datebox
Combobox
Chosenbox
Selectbox

Specify Events to Block

If you just want to block particular events, not all events. Then, you can specify a list of events in zk.xml like below to control the behavior of InaccessibleWidgetBlockService. For example,

<library-property>
	<name>org.zkoss.zkmax.au.IWBS.events</name>
	<value>onClick,onChange,onSelect</value>
</library-property>

Implement Your Own Blocking Rules

If you want to block a request for inaccessible widgets for the whole application or for a particular desktop, you can implement the AuService interface to filter out unwanted requests. The implementation of AuService is straightforward. For example, the following example blocks only onClick of Button:

public class MyBlockService implements org.zkoss.zk.au.AuService {
	public boolean service(AuRequest request, boolean everError) {
		final Component comp = request.getComponent();
		return (comp instanceof Button) && "onClick".equals(request.getCommand());
			//true means block
	}
}




Last Update : 2024/04/18

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.