name attribute of an element to the Page Field Name (if provided) or to RECNAME_FIELDNAME of the field (if Page Field Name is empty).
An Exploratory Example
This can be illustrated by the following example.
Note the following in DEMO_PG:
The HTMLArea contains the following constant:
<input title='Enter a text value' type='text' name='MOD_BY_JS' value=''/>
And then, the following PeopleCode was added to DEMO_TBL.TEXT1.FieldChange:
DEMO_TBL.LONGVALUE = "DEMO_TBL.TEXT1 has the following value: " | DEMO_TBL.TEXT1;
Now, see the page in action.
When the Save button is clicked, a trip to the server is performed. During each trip, all form elements on the page is sent to the server. Because we’ve set the name attribute of the input element on the HTML Area to be the same as the Page Field Name of the
DEMO_TBL.TEXT1 field on the page, the value of the input element is associated with
On the first Save action, the component receives the value of “Hello” and detects the change. Therefore, it updates the value of
DEMO_TBL.TEXT1 in the component buffer and executes the FieldChange. When the page was refreshed, we can see that the
LONGVALUE field was indeed updated by the PeopleCode.
What’s the problem? When the page was refreshed after the first save, the input element became empty again. This is because the value of the input element stored in the HTML Area page field didn’t change. When PeopleTools rewrites the HTML page, it simply takes the contents of the HTML Area and re-insert it on the specific point in the page. It would be the developer’s responsibility to update the content of the HTML Area. Remember: the developer is in control of rendering the element.
When the page is saved the second time, the value of the input element sent to the server is blank. This is different from the value in the component buffer, which currently have the value of “Hello”. Again, the component processor detected this change, updated the component buffer, and triggered the FieldChange PeopleCode.
The following PeopleCode was added to DEMO_TBL.TEXT1.RowInit:
DERIVED_WORK.HTMLAREA = "<input title='Enter a text value' type='text' name='MOD_BY_JS' value='" | DEMO_TBL.TEXT1 | "'/>";
The input element must also be updated when the field value is changed. So, the same code was also added to DEMO_TBL.TEXT1.FieldChange, giving:
DEMO_TBL.LONGVALUE = "DEMO_TBL.TEXT1 has the following value: " | DEMO_TBL.TEXT1; DERIVED_WORK.HTMLAREA = "<input title='Enter a text value' type='text' name='MOD_BY_JS' value='" | DEMO_TBL.TEXT1 | "'/>";
Let’s see the page in action.
The value in the input element is updated to reflect the values of DEMO_TBL.TEXT1. This is done when the component buffer is initialized and when the buffer data is changed. The result is the expected behavior of an edit box.
What’s the problem? When the value
'><hr title='hi was saved into
DEMO_TBL.TEXT1, the resulting content of the HTML Area became
<input title='Enter a text value' type='text' name='MOD_BY_JS' value=''><hr title='hi'/>
By closing the input tag, the user was able to introduce another HTML element—a horizontal rule—into the page.
The issue is somewhat similar to SQL Injection. However, the reader may initially think this is benign because it just involves HTML rendered on a page, and the result would just be a broken page layout. Actually, if the length of TEXT1 is long enough, it will be open to a Type-2 XSS exploit. So, it is imperative that this issue should be always considered and addressed.
Modification. To address this issue, the data must be properly escaped in the HTML. The PeopleCode function
EscapeHTML() is designed to do this. The PeopleCode that updates the HTML Area is modified as follows:
DERIVED_WORK.HTMLAREA = "<input title='Enter a text value' type='text' name='MOD_BY_JS' value='" | EscapeHTML(DEMO_TBL.TEXT1) | "'/>";
Again, let’s see the page in action.
The length of the TEXT1 field is only 15 characters. Even though the value sent to the server is more than 15 characters, the component enforces the 15 character limit and ignores the excess characters. This is a good security feature. The only issue is that our application isn’t user-friendly by allowing the user to enter more characters than the server would accept.
Modification. Finally, one last tweak to address this is to add a maxlength attribute to the input element. The PeopleCode that populates the HTML Area is changed to:
DERIVED_WORK.HTMLAREA = "<input title='Enter a text value' type='text' name='MOD_BY_JS' maxlength='15' value='" | EscapeHTML(DEMO_TBL.TEXT1) | "'/>";
- When using this for displaying your custom control, make sure that the HTML Area is always updated with the current value. RowInit and FieldChange are normally the only location where you need to do this.
- Always escape the data written back to the page
- When the entire page is set to display-only by PeopleCode, the server would also ignore any changes coming from the client
Notice how all the disabled input fields are suddenly editable. Now, try editing those fields and perform a server-side action like saving. PeopleSoft will simply ignore whatever values are in the disabled fields. In essence, the Application Server keeps track of what fields are editable and does not accept all data posted by the client.
 This is true only for level 0. For lower levels, a suffix of $n is needed where n depends on the occurs instance of the field on the page.