| Oracle® Application Express Application Builder User's Guide Release 3.2 E11947-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Application Express Application Builder User's Guide Release 3.2 E11947-03 |
|
|
PDF · Mobi · ePub |
This section describes security best practices for Oracle Application Express developers.
Topics in this section include:
Password items do not emit the text entered to the Web browser screen. When creating items of type password, Oracle recommends using password item types that do not save session state. This prevents the password from being saved in the database in the session state tables.
Available password item types include:
Password - Suppresses text entered into the field. Saves the value in session state when the page is submitted.
Password (submits when Enter pressed) - Suppresses text entered into the field and submits the page when ENTER is pressed.
Password (does not save state) - Suppresses text entered into the field. Does not save the value in session state.
Password (submits when Enter pressed, does not save state) - Suppresses text entered into the filed and submits the page when Enter is pressed. Does not save the value in session state.
The Password and Password (submits when Enter pressed) save the password in a database table when the page is submitted. Use these password item types only when the password is needed in session state for use by other pages during the session.
Password (does not save state) and Password (submits when Enter pressed, does not save state) do not save the password in a database table. Use these password item types when the submitted password value is used only by after-submit page processing on the same page and is never needed again during the session.
If you must reference and retrieve the value of a password in your application then you should set the Store value encrypted in session state attribute to Yes. To learn more, see "About Session State and Security".
See Also:
"About Item Types"At risk password items are those that either:
Do not use one of the password item types that does not save session state
Store the value in session state un-encrypted
Use the Password Items, Security Profiles, and Password Items report to help identify at risk password item:
To view reports that identify at risk password item types:
Navigate to the Workspace home page.
Click the Application Builder icon.
Select an application.
The Application home page appears.
On the Tasks list, click Application Reports.
To view the Password Items report:
Select Page Components.
Under Items, click Password Items.
This report shows all of the password items within the application and indicates if they use encryption and whethere they save state. Password items that do neither are highlighted as At Risk.
To view the Security Profiles report:
Select Cross Application.
Under Items, click Password Items.
To view the Password Items report:
Select Cross Application.
Under Items, click Security Profiles.
Notice the At Risk Password Items column.
For pages that contain password items, set page attribute Form Auto Complete to Off. Setting that attribute to Off prevents the Web browser from attempting to auto complete items on the page. To learn more about this attribute, see Table 5-6.
When users access Oracle Application Express application pages, numerous links containing session IDs become visible in the Web browser's location window. If the application is publicly accessible and the user communicates one of these links to another application user, for example by using email or a messaging service, the recipient can use the link and immediately begin sharing the original user's session. This can have a negative effect on both users as they use the application and lead to unpredictable, hard to reproduce screen behavior. To prevent this, Oracle recommends the use of the Zero Session ID feature for all applications where users are not required to provide login authentication. To learn more, see "Facilitating Bookmarks by Using Zero as the Session ID".
Cross site-scripting (also referred to as XSS) is a security breach that takes advantage of dynamically generated Web pages. In a XSS attack, a Web application is sent a script that activates when it is read by a user's browser. Once activated, these scripts can steal data, even session credentials, and return the information to the attacker.
If malicious code were introduced into an Oracle Application Express application, it could be rendered into HTML regions and other places within the application during normal page rendering. To prevent the introduction of malicious code into session state, the Application Express engine escapes characters in certain cases.
Topics in this section include:
In HTML regions and other static display areas, you can reference session state using the &ITEM. notation. Examples of static display areas include HTML regions, page headers and footers, region headers and footers, region titles, button labels, help text, form item labels and post-element text, templates, radiogroup (before and after field text), event success messages, event error messages, navigation bar attributes, application static substitution string values, chart labels and legends, breadcrumbs and list framing text, and calendar text, labels, or legends.
When session state is referenced in this way, the value emitted to the page will not have special characters (<, >, &, ") escaped if the referenced item is one of the following safe item display types:
Display as Text (does not save state)
Display as Text (escape special characters, does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PL/SQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
If the referenced item has a display type other than one of the above types, the value emitted to the page will have special characters escaped. Although application-level items are also considered to have a safe display type, they do not actually have display properties like form items do.
See Also:
"Understanding Page-Level Items"The Application Express engine uses predefined smart escaping rules to determine if and when to escape values fetched from session state.
The reason for these rules is that items that use the display types listed previously are often for text containing HTML that is intended to be emitted to the browser without being filtered (that is, escaped). The only way this can be made safe is by the enforcement of the rule that these types of items are always escaped on input to the application. For example, if a user passes some text into a safe item using an Oracle Application Express f?p URL syntax, the Application Express engine escapes special characters when saving the value into session state. This has two intended results:
If the value contained no special characters, the value passed in is saved into session state exactly as it was provided.
If the value contained special characters, those characters are escaped when the value is saved into session state.
In either situation, the item can now safely be referenced using an &ITEM. notation in any HTML region or other static area mentioned previously.
You can use the safe item types listed previously to hold and emit HTML markup to the browser. For example, suppose you have a requirement to render some text in bold face by referencing a safe page item named P1_XXX (using &P1_XXX.) The item P1_XXX is presumed to contain the following HTML:
<b>ABABABAB</b>
You can achieve this by using application controls (computations, processes, item source expressions, item default values, and so on) to store values into these safe items. When values are introduced in this way, you ensure the safety of the content. When you use these methods, the Application Express engine does not escape any special characters when saving the values into session state.
Finally, the safety of safe items is ensured by a rule that prevents those items from being posted on a page and submitted to the Application Express engine as part of a page submission.
Items fetched from session state and rendered using htp.p or other methods should be explicitly escaped by the code where it is appropriate to do so. For example, suppose a PL/SQL dynamic content region on a page uses the following:
htp.p(v(’SOME_ITEM'));
If the value of the item fetched from session state could contain unintended tags or scripts, you might want to use the following in the region:
htp.p(htf.escape_sc(v(’SOME_ITEM')));
However, if you are confident that the fetched value is safe for rendering, you do not need to escape the value. As a developer, you need to determine when it is appropriate to not escape output.
As a best practice, follow this rule:
Never emit an item fetched from session state without escaping it unless the item is one of the safe types described in "About Safe Item Display Types".
The reason for this is that as a developer, there is no way you can prevent a hacker from posting a malicious value into a non-safe item. Even if your application does not present these items visibly to ordinary users, be aware that a hacker can mount a XSS attack using your application if you do not follow this rule.
The Application Express engine escapes data rendered in the body of a report. References to session state in report headings and messages are fetched from session state using the smart escaping rules so that the values of safe item types are not escaped and the values of other item types are escaped.
When form items, including hidden items, obtain their values during the generation of the form page to be sent to the browser, the resulting text is escaped before rendering. Some of the safe item types are exceptions to this rule in order to support the intended behavior of each display type.
Oracle Application Express persists session state in database tables. Session state is preserved in database tables because it is more secure to store the session state on the server side than on the client. Because Oracle Application Express applications use the stateless HTTP protocol, an application's session state across multiple page views is preserved in database tables. Not maintaining a synchronous database connection for each Oracle Application Express application user significantly lessens memory and database resource requirements.
Developers can query the session state stored by Oracle Application Express applications using the Application Builder and built-in monitoring pages. Developers and administrators can access session state for any application in the workspace to which they are authenticated.
A few best practices for developers include:
As a standard part of implementing program control flow, clear the session state of unneeded values using clear-cache page processes or clear-cache directives in URLs used to navigate to pages.
Use password page item types that do not save state. This prevents the entered passwords from being saved in session state tables in the database.
When sensitive data must persist in a session, it should be saved in Oracle Application Express session state tables in encrypted form. To use this feature, set the page item's Store value encrypted in session state attribute to Yes. Encrypted stored values are automatically decrypted when read.
Note:
The objective of encrypted session state is to persist session state such that the unencrypted values cannot be read by other Oracle Application Express developers or database administrators who might have access to the Oracle Application Express session state tables, debug output, or database data files. Oracle recommends that database backups be performed using facilities that encrypt data in the backup files.Tip:
You can encrypt item values up to 4000 bytes in length. Attempts to encrypt values longer than 4000 bytes produces an error message.Session State Protection is a built-in functionality that prevents hackers from tampering with the URLs within your application. URL tampering can adversely affect program logic, session state contents, and information privacy.
Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes.
Topics in this section include:
When enabled, Session State Protection uses the Page Access Protection attributes and the Session State Protection item attributes with checksums positioned in f?p= URLs to prevent URL tampering and unauthorized access to and alteration of session state. When Session State Protection is disabled, the page and item attributes related to session state protection are ignored and checksums are not included checksums in generated f?p= URLs.
You can enable session state protection from either the Edit Security Attributes page or the Session State Protection page.
Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes. You can perform these steps using a wizard, or you can set security attributes for pages and items manually on the Session State Protection page.
Topics in this section include:
Enabling Session State Protection from Edit Security Attributes
Enabling Session State Protection from Session State Protection
To enable Session State Protection from the Edit Security Attributes page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click the Shared Components icon.
Under Security, click Edit Security Attributes.
Scroll down to Session State Protection and select Enabled from the Session State Protection list.
To configure session Session State Protection, click Manage Session State Protection.
The Session State Projection page appears.
Navigate to the Edit Security Attributes page to set page and item security attributes.
Tip:
To disable Session State Protection, perform the same steps again, but select Disabled instead of Enabled. Disabling Session State Protection will not change existing security attribute settings, but those attributes will be ignored at run time.Enabling Session State Protection affects whether bookmarked links to the current application will work. Consider the following rules:
Bookmarked links created after Session State Protection is enabled will work if the bookmarked link contains a checksum.
Bookmarked links created before Session State Protection is enabled will not work if the bookmarked link contains a checksum.
Bookmarks that do not contain checksums or contain unnecessary checksums will not be affected by Session State Protection.
During page rendering, the Application Express engine uses a hidden application attribute (a checksum salt) during computation and to verify checksums included in f?p URLs. When you enable Session State Protection, the Application Express engine includes checksums. You can reset the checksum salt attribute by clicking Expire Bookmarks on the Edit Security Attributes page. Note that if you click Expire Bookmarks, bookmarked URLs used to access your application that contain previously generated checksums will fail.
To enable Session State Protection:
Navigate to the Shared Components page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears. Note the current Session State Protection status (Enabled or Disabled) displays at the top of the page.
Click the Set Protection button.
The Session State Protection wizard appears.
Under Select Action, select Enable and click Next.
Next, determine whether to set security attributes for pages and items.
Select Enable and click Next.
Click Enable Session State Protection.
Tip:
To disable Session State Protection, perform the same steps, but select Disable instead of Enable. Disabling Session State Protection will not change existing security attribute settings, but those attributes will be ignored at run time.Once you have enabled Session State Protection, the next step is to configure security attributes. You can configure security attributes in two ways:
Use a wizard and select a value for specific attribute categories. Those selections will then be applied to all pages and items within the application.
Configure values for individual pages, items, or application items.
Topics in this section include:
Tip:
Before you can configure security attributes, you must first enable Session State Protection. See "Enabling Session State Protection".You can review a summary of Session State Protection settings for pages, items, and application items on the first page of the Session State Protection wizard.
To view summaries of existing Session State Protection settings:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click Set Protection.
Expand the following reports at the bottom of the page:
Page Level Session State Protection Summary
Page Item Session State Protection Summary
Application Item Session State Protection
When you configure Session State Protection using a wizard, you set a value for specific attribute categories. Those selections are then applied to all pages and items within the application.
To configure Session State Protection using a wizard:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click Set Protection.
The Session State Protection wizard appears.
Under Select Action, select Configure and click Next.
For Page Access Protection, select one of the following:
Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).
Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.
No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.
No URL Access - The page may not be accessed using a URL; however, the page may be the target of a Branch to Page branch type, which does not do a URL redirect.
For Application Item Protection, select one of the following:
Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is also provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled.
Use this attribute for application items or for page items with any of these Display As types:
Display as Text (escape special characters, does not save state)
Display as Text (does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PLSQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
For Page Data Entry Item Protection, select one of the following:
Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
For Page Display-Only Item Protection, select one of the following:
Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled.
This attribute may be used with any of these Display As types:
Display as Text (escape special characters, does not save state)
Display as Text (does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PLSQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
Click Next.
Click Finish.
To configure Session State Protection for Pages:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Page icon.
To filter the view, use the Page, Display, and Page Access Protection lists at the top of the page.
Select a page number.
The Set Page and Item Protection page appears. The following information displays at the top of the page:
Application ID and name
Session State Protection status (Enabled or Disabled)
Page Number
Page name
For Page Access Protection, select one of the following:
Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).
Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.
No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.
No URL Access - The page may not be accessed using a URL; however, the page may be the target of a Branch to Page branch type, which does not do a URL redirect.
For Item Types, select Data Entry Items or Display-only Items.
Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.
If you select Data Entry Items, select a session state protection level for each item:
Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
If you select Display-only Item, select a session state protection level for each item:
Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:
Display as Text (escape special characters, does not save state)
Display as Text (does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PLSQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
Click Apply Changes.
To configure Session State Protection for items:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Item icon.
To filter the view, select from the Page, Display, and Item Session State Protection lists at the top of the page and click Go.
Select a page number.
The Edit Session State Protection for Page and Items page appears. The following information displays at the top of the page:
Application ID and name
Session State Protection status (Enabled or Disabled)
page Number
Page name
For Page Access Protection, select a session state protection level for each item:
Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).
Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.
No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.
No URL Access - The page may not be accessed using a URL, however the page may be the target of a Branch to Page branch type, which does not do a URL redirect.
For Item Types, select Data Entry Items or Display-only Items.
Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.
If you select Data Entry Items, select a session state protection level for each item:
Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
If you select Display-only Item, select a session state protection level for each item:
Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:
Display as Text (escape special characters, does not save state)
Display as Text (does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PLSQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
Click Apply Changes.
To configure Session State Protection for application items:
Navigate to the Session State Protection page:
On the Workspace home page, click the Application Builder icon.
Select an application.
Click Shared Components.
Under Security, select Session State Protection.
The Session State Protection page appears.
Click the Application Item icon.
Select an application item.
Under Security, select one of the following from the Session State Protection list:
Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.
Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is only applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled. This attribute may be used for application items or for page items with any of these Display As types:
Display as Text (escape special characters, does not save state)
Display as Text (does not save state)
Display as Text (based on LOV, does not save state)
Display as Text (based on PLSQL, does not save state)
Text Field (Disabled, does not save state)
Stop and Start HTML Table (Displays label only)
Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.
Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.
Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.
Click Apply Changes.
|
 Copyright © 2003, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
