Secured Fields

From Plex-XML

Secured fields are protecting the integrity of all data in a web page which should not be modified by the client (output or hidden fields, links, etc.).

In Plex-XML secured fields are web form fields that are protected against Web Parameter Tampering by a hash code. The hash code is generated and checked on the server, it is MD5 encoded and based on the field content plus some other varying values. It will be appended on the request URL as h parameter. If the content of one of the secured field is changed by the user the hash code won't match, the request is denied and the user will get an error message.

The hash code is created from an internal session id, the request name, the content of the secured fields and an fixed part that could be specified in the web.xml. The useSession= false attribute could be used to disable the SessionId in hash code. Useful for anonymous requests.

<!-- Example URL with hash code for DOCENT and DOCFK1-->
http://.../plex?request=DocFilFB&DOCENT=Foo01&DOCFK1=Foo02&h=3838fc52dea2b6cb7a48c454e8681ef0

To achieve a maximum flexibility the hash code generation is not done in Plex. If you try to generate the hash code in Plex each web request has to know the web requests it links to on design time. Otherwise it won't know the secured fields and values for the hash code generation. This means that you need to knit all your web requests together within your Plex model. This also means that you can't link Plex functions from models that are not inheriting from each other into one secured web application.

To get around this limitation of other web solutions the hash code generation in Plex-XML is done in the XSLT part. Every time you define in XSLT a link from one HTML page to another (from one web request to another) the Request Configuration is checked for secured fields and the hash code is automatically appended to the URL. The same is done on the receiving part of the servlet where the Request Configuration is checked for the necessity of a hash code, the hash code is checked by the servlet and if the hash code won't match the access is denied by the servlet without getting through any Plex-Function or Business-Logic.

The definition which fields are secured is done in the web request configuration. See below an example with two secured fields DOCENT and DOCFK1:

<!-- Example request configuration with secured fields for DOCENT and DOCFK1-->
<webrequest name="DocFilFB">
  <secfields>
    <field name="DOCENT"/>
    <field name="DOCFK1"/>
  </secfields>
  <request name="DocFilFB" extends="FindBrowse">
    <plex-parameter type="web" name="Input_DocFileEntity">DOCENT</plex-parameter>
    <plex-parameter type="web" name="Input_DocForeignKey1">DOCFK1</plex-parameter>
  </request>  
  ...

If you use secured field in a DictionaryFindBrowse like it is done in the example above you need to call the <appendHashFields> template from your XSLT. This template takes care for the hidden fields that will be used for the hash code validation.

<xsl:template name="otherHiddenFields">
  <xsl:variable name="DOCENT" select="$vPath/returnvalue[@name='DocFileEntity']/@unformatted"/>
  <xsl:variable name="DOCFK1" select="$vPath/returnvalue[@name='DocForeignKey1']/@unformatted"/>

  <xsl:call-template name="appendHashFields">
    <xsl:with-param name="param">
      <param value="{$DOCENT}">DOCENT</param>
      <param value="{$DOCFK1}">DOCFK1</param>
    </xsl:with-param>
  </xsl:call-template>

</xsl:template>

For each automatically generated link or web request and each onClick handler the XSLT takes care of secured fields. If you need more flexibility you could call the generateHashCode template where necessary.