Triple’A Plus® Web contains more than needed in a production environment. One way of knowing it is for example to look at the front end code for example like the main client side script xgui2html.js. The debug instructions are coupled with the logic or the debug toolbar that is inserted in the layout via the green dot appearing on the top right of the screen.
Another example is the delivery of several cocoon views for debugging purpose. Appending to the http query string the parameter cocoon-view with a certain value activates a view of the page. For example: with the value pdf the page (activity) is rendered as a PDF document, with the xls value as an Excel spreadsheet, i18n-content as an XML document containing the translations but before HTML generation.
The list of cocoon views supported by the WUI is not defined completely in the sitemap of the application… In the table below the views and their purpose.
- content: the raw XMLview
- popup: view that is exclusively used for popup windows / not suitable for mobile applications
- layer: this view opens the target as a layer in the main window
- pdf: renders the current page as a PDF document
- xls: renders the current page as an Excel spreadsheet
- frame: view that is used when the page is to be included as an html frame document
- embed: view that embeds the activity/modules in a page. This view is mainly used in portals
- analyze: this compares the page against the scheme and will reveal the violations of the scheme rules on the screen as HTML.
- xsource: aka XGUI Source Code Analyzer, is very similar
- i18n-keys: The WUI is rendered as an HTML document without the i18n translations replacement
- i18n-content: returns the result as XML document after i18n keys replacement and before HTML serialization.
If they are very useful for development purpose, they constitute a security risk as they can provide information before the HTML transformation. Inside a secured and controlled network, the threat is purely internal but when the application allows clients to connect externally, they shall be removed from the sitemap.
This post is about how to do it and deliver it in a customization package
Create a project based on the custo-manual template with as custo value: wui-sitemap. The project name in the DS navigator will appear as: wui-sitemap-custo-manual.
After the regular clean-up of the project artifacts like the helloworld.cmd script, the correct setup of the block.xml file (id & weight), create a block.xmap file in the src/main/resources/Block-inf folder.
The views that can be removed are
<!-- =============================================================================== SITEMAP PATCH =============================================================================== Block Name: WUI-SITEMAP-CUSTO-MANUAL =============================================================================== --> <patches> <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='analyze']"></patch> <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='xsource']"></patch> <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='i18n-keys']"></patch> <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='i18n-content']"></patch> </patches>
Adapt the file content to your needs: add or remove patch tag node as you wish or change the value in the @name attribute. After that, add the project to the embedded server, start it and after the login, append “cocoon-view=i18n-content”. If you see something else than an HTML page, it means the patch isn’t properly applied.
In conclusion, this project can be packaged separately, to install it only in a production environment or wherever needed.