Difference between revisions of "Opentaps Google Web Toolkit"
(→Building GWT) |
(→Security) |
||
Line 29: | Line 29: | ||
Your GWT widgets will need to interact with server-side services to store and retrieve data. A "best practices" pattern we have started in opentaps is to create a configuration Java file for each server side service available for GWT client-side widgets. For example, there is a <tt>org.opentaps.gwt.crmsfa.contacts.client.form.configuration.QuickNewContactConfiguration</tt> Class which contains the server-side URL and all the form parameters for interacting with the quick new contact service on the server. This is part of the GWT client package and is designed to be used by all the client-side widgets. Note that the pattern is to have one Configuration Java file for each ''server''-side service, to be shared by many client-side widgets which may access the same server-side service, not to have a configuration file for each client-side widget. | Your GWT widgets will need to interact with server-side services to store and retrieve data. A "best practices" pattern we have started in opentaps is to create a configuration Java file for each server side service available for GWT client-side widgets. For example, there is a <tt>org.opentaps.gwt.crmsfa.contacts.client.form.configuration.QuickNewContactConfiguration</tt> Class which contains the server-side URL and all the form parameters for interacting with the quick new contact service on the server. This is part of the GWT client package and is designed to be used by all the client-side widgets. Note that the pattern is to have one Configuration Java file for each ''server''-side service, to be shared by many client-side widgets which may access the same server-side service, not to have a configuration file for each client-side widget. | ||
− | === | + | ===Permission=== |
− | Client-side | + | The GWT widgets do not perform security checks, but users permissions are made available to them in order to adapt the user interface accordingly. The real security checks allowing a user to perform an operation or retrieve data are performed server side. |
+ | |||
+ | Client-side permission checking is handled in the following way: | ||
# The server side uses the <tt>User</tt> object to determine what permissions the currently logged in user has and puts it into the webpage sent to the client as an object using JavaScript. This is done in the <tt>main-decorator.bsh</tt> and <tt>header.ftl</tt> of the server. | # The server side uses the <tt>User</tt> object to determine what permissions the currently logged in user has and puts it into the webpage sent to the client as an object using JavaScript. This is done in the <tt>main-decorator.bsh</tt> and <tt>header.ftl</tt> of the server. | ||
# On the client-side, the <tt>Permission</tt> class retrieves the security permissions set into the browser via JavaScript. Your GWT widget can use its <tt>hasPermission</tt> method to check if the user has permissions to access certain sections of your page: | # On the client-side, the <tt>Permission</tt> class retrieves the security permissions set into the browser via JavaScript. Your GWT widget can use its <tt>hasPermission</tt> method to check if the user has permissions to access certain sections of your page: | ||
Line 40: | Line 42: | ||
</pre> | </pre> | ||
− | '''WARNING''': Do not | + | '''WARNING''': Do not rely on those checks to hide sensitive data or services from a user. Specifically, it is possible for the end user to modify the JavaScript add permissions for their displayed widgets. Therefore, you should always filter out sensitive data before sending them to the client-side widgets, and every operation on the server side should check permissions again. Client-side widget permission checking is only for hiding parts of the user interface and should not be considered a security feature. |
Revision as of 14:58, 26 November 2008
Building GWT
The Google Web Toolkit (GWT) is built independently of opentaps. To build the Google Web toolkit widgets,
$ ant gwt
To clear the previous build,
$ ant clean-gwt
This will cause ant to look for look "gwt" in the opentaps components' build.xml files and build them one at a time. In the component build.xml, the following directories are specified for building gwt:
<property name="gwt.deploy.dir" value="./webapp/crmsfagwt"/> <property name="gwt.module.base" value="org.opentaps.gwt.crmsfa"/> <property name="gwt.src.common" value="../opentaps-common/src/org/opentaps/gwt"/> <property name="gwt.src.base" value="./src/org/opentaps/gwt/crmsfa"/>
Then, when ant tries to build gwt, it will look all that gwt modules specified in the build.xml. Each module is specified at a path of ${gwt.deploy.dir}/${gwt.module.base}.${module}.${module} For example, if you specify contacts as the module to compile, then opentaps will try to compile org.opentaps.gwt.crmsfa.contacts.contacts.gwt.xml, which should be in your src/ path.
When you have an additional GWT module to build, add it to the list of modules:
<foreach list="contacts,accounts,leads,partners" target="gwtcompile" param="module"/>
To speed up the build during development, you can setup GWT to only compile for one of the supported browsers. This is configured in the common module in hot-deploy/opentaps-common/src/org/opentaps/gwt/common/common.gwt.xml. For example, you can enable it for only Mozilla/Firefox by setting the user.agent property to "gecko1_8":
<set-property name="user.agent" value="gecko1_8"/>
Configuring Server Side Interaction
Your GWT widgets will need to interact with server-side services to store and retrieve data. A "best practices" pattern we have started in opentaps is to create a configuration Java file for each server side service available for GWT client-side widgets. For example, there is a org.opentaps.gwt.crmsfa.contacts.client.form.configuration.QuickNewContactConfiguration Class which contains the server-side URL and all the form parameters for interacting with the quick new contact service on the server. This is part of the GWT client package and is designed to be used by all the client-side widgets. Note that the pattern is to have one Configuration Java file for each server-side service, to be shared by many client-side widgets which may access the same server-side service, not to have a configuration file for each client-side widget.
Permission
The GWT widgets do not perform security checks, but users permissions are made available to them in order to adapt the user interface accordingly. The real security checks allowing a user to perform an operation or retrieve data are performed server side.
Client-side permission checking is handled in the following way:
- The server side uses the User object to determine what permissions the currently logged in user has and puts it into the webpage sent to the client as an object using JavaScript. This is done in the main-decorator.bsh and header.ftl of the server.
- On the client-side, the Permission class retrieves the security permissions set into the browser via JavaScript. Your GWT widget can use its hasPermission method to check if the user has permissions to access certain sections of your page:
if (!Permission.hasPermission(Permission.CRMSFA_CONTACT_CREATE)) { return; }
WARNING: Do not rely on those checks to hide sensitive data or services from a user. Specifically, it is possible for the end user to modify the JavaScript add permissions for their displayed widgets. Therefore, you should always filter out sensitive data before sending them to the client-side widgets, and every operation on the server side should check permissions again. Client-side widget permission checking is only for hiding parts of the user interface and should not be considered a security feature.