Block Request for Inaccessible Widgets"

From Documentation
Line 5: Line 5:
  
  
= Non-existed Component is Safer than Invisible One =
+
= 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) 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:
  
Line 12: Line 12:
 
<button visible="${accessible}"/>
 
<button visible="${accessible}"/>
 
</source>
 
</source>
 
  
 
= Block with <tt>InaccessibleWidgetBlockService</tt> =
 
= Block with <tt>InaccessibleWidgetBlockService</tt> =

Revision as of 08:17, 7 July 2021


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) 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:

<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 Enterprise Edition provides a InaccessibleWidgetBlockService to block events sent from inaccessible widgets with a default rules. Because the default rules might not apply to all use cases, ZK doesn't enable this service by default.

Limitation

Verifying user permission or available actions should be a business class's responsibility instead of a UI framework. Hence, this service should not play the main role to determine the available actions. It can work as a filter (a helper) that just blocks some general cases before your business class verifies the user permission, which can save the cost.


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
  • Not block onOpen

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 zk.xml 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>

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


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 button and onClick:

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
	}
}

Version History

Last Update : 2021/07/07


Version Date Content
8.0.3 2016/09/21 Add "supported components" table
     



Last Update : 2021/07/07

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