5 Page Design and Caching

This chapter describes how WebCenter Sites caching works. Caching your web pages can improve your site's performance. Whether your site is static or dynamic, you need to design your site so that part or all of a given page is cached.

This chapter contains the following sections:

5.1 Modular Page Design

It is recommended that you design your web pages using a modular page design strategy, where a web page that a website visitor sees is composed of multiple elements. Modular page design has several benefits:

  • It improves system performance by allowing you to develop an efficient caching strategy

  • It lets you code common design elements, like navigation bars, one time and use them on multiple web pages

The following diagram shows a simple modular page:

Figure 5-1 A modular page

Description of Figure 5-1 follows
Description of "Figure 5-1 A modular page"

Each rectangle represents a pagelet (the generated output of one or more elements). These pagelets are called by a containing page. The containing page lays out how the pagelets appear on the finished page and contains any code that must be evaluated each time the page is viewed (custom ACL checking code, for example). This strategy lets you code an element once and use it in many places in your website.

5.2 Caching

WebCenter Sites lets you cache entire web pages and/or the components that make up those web pages. An efficient page caching strategy improves system performance by reducing load.

Two members of the WebCenter Sites product family implement page caching:

  • WebCenter Sites, which caches pages on the WebCenter Sites system

  • Satellite Server, which provides a second level of caching for your WebCenter Sites system, and can also be used as a remote cache for your web pages

WebCenter Sites utilizes both the WebCenter Sites and Satellite Server caches to create an efficient caching strategy.

5.2.1 WebCenter Sites Caching

Pagelets generated by requests to the ContentServer servlet can be cached on disk. If a page is accessed frequently and its content depends on a small number of parameters, then it is a good candidate for disk caching.

To disk-cache a pagelet, you use one of the following tags:

Table 5-1 Caching Tags

JSP Tag XML Tag

satellite:page

SATELLITE.PAGE

render:satellitepage

RENDER.SATELLITEPAGE


If the pagelet that you want to cache is not already in the disk cache, ContentServer adds it to the cache and then serves the pagelet. If the specified pagelet is already in the disk cache, ContentServer simply serves it.

The expiration of disk-cached pagelets is time-based and governed by properties in the futuretense.ini file, in conjunction with the values set in the cscacheinfo and sscacheinfo columns of the SiteCatalog table (cscacheinfo corresponds to the WebCenter Sites servlet; sscacheinfo corresponds to the Satellite Server servlet). When a cached page is requested, its expiration time (cache timeout) is stored in the etime column of the SystemPageCache table. The expiration time for cached pages requested through the WebCenter Sites servlet is calculated from the cscachinfo value, and the expiration time for cached pages requested through the Satellite Server servlet is calculated from the sscacheinfo value. Items in cache are bound by the same security rules as uncached pages; WebCenter Sites ACLs apply to cached pagelets just as they do to elements.

5.2.2 BlobServer and Caching

The term blob is an acronym for binary large object. Although a blob is usually an image file, a blob can be any binary object, including a Microsoft Word file or a spreadsheet. Most websites serve a number of blobs.

To serve blobs, WebCenter Sites offers a special servlet called BlobServer. The BlobServer gathers a blob from a table and performs all relevant security checks.

You access BlobServer with the BlobServer tags:

  • satellite:blob

  • render:satelliteblob

Both of these tags cache blobs in the WebCenter Sites and Satellite Server caches. For more information about the BlobServer tags, see the Oracle Fusion Middleware WebCenter Sites Tag Reference.

Deleting Blobs from the WebCenter Sites Memory Cache

To delete a specific blob from the WebCenter Sites cache, you must do the following in the BlobServer URL:

  • Rename the blobtable parameter to flushblobtable

  • Authenticate as a user with SiteGod privileges by passing credentials through the authusername and password parameters

For example:

http://hostname:port/servlet/BlobServer?blobcol=urlpicture&blobheader=image%2Fgif&blobkey=id&flushblobtable=NewPortalImage&blobwhere=22&authusername=username&authpassword=password

To delete all blobs, rename the blobtable parameter to flushblobtables (notice the "s") and set its value to true.

5.2.3 Satellite Server Caching

Satellite Server, automatically installed with WebCenter Sites, provides an additional layer of caching. To improve your WebCenter Sites system's performance, you can add remote Satellite Server systems, putting your content closer to its intended audience.

Satellite Server caches pages, pagelets, and blobs to disk or to memory. You can use the Inventory servlet to view the contents of the memory and disk caches in varying degrees of detail. Note that items cached on Satellite Server are not protected by WebCenter Sites APIs. You can overcome this limitation by using the caching strategy outlined in Section 5.4.1.1, "Pagelet Caching Strategies."

Satellite Server caches small items to memory and large items to disk. You control the definitions of small and large through the file_size property. For more information on setting Satellite Server properties, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.

On a busy site, each Satellite Server system's cache fills up quickly with the most popular pages. When the cache is full, Satellite Server deletes old pages to make room for new ones. Satellite Server uses a Least Recently Used algorithm (LRU) to determine which items should be removed from the cache. In other words, when a new page needs to be cached, Satellite Server removes the page that hasn't been accessed for the longest time. For example, given two cached pages, one that hasn't been accessed in 36 hours and the other that hasn't been accessed in 2 hours, Satellite Server removes the page that hasn't been accessed in 36 hours.

5.2.3.1 Cache Expiration

Page and pagelet expiration on Satellite Server is specified in the sscacheinfo column of the SiteCatalog table. Each time a page or pagelet is invoked through Satellite Server, Satellite Server processes the sscacheinfo field's value and determines when the page or pagelet should expire. Consult Section 7.4, "CacheInfo String Syntax" in Chapter 7, "Advanced Page Caching Techniques"for information about the sscacheinfo field.

Note:

Deprecation notice: It is possible to override the sscachinfo expiration information for pagelets by specifying the cachecontrol attribute in the satellite.page and render.satellitepage tags. However, this practice is deprecated because it can lead to non-deterministic behavior; some pagelets may be accessed through the default method (without the cachecontrol attribute) while others may be accessed with an override. The first method invoked will set the expiration for Satellite Server, and the second one will have no effect on the expiration.

Blobs cached on Satellite Server expire using the following algorithm:

  • You can use Satellite Server tags to override the default expiration time on a blob-by-blob basis.

  • If there is no Satellite tag to override the default expiration, Satellite Server gets the expiration time from the value of the satellite.blob.cachecontrol.default property. This property is described in Section 5.3.4.1, "WebCenter Sites Page Caching Properties."

  • If no value is set for the satellite.blob.cachecontrol.default property, Satellite Server gets the expiration time from the value of the expiration property, described in Section 5.3.4.2, "Satellite Server Properties."

5.2.3.2 Caching with the Satellite Servlet

The following sections describe how the Satellite servlet caches web pages and how you can implement Satellite Server caching on your site. Use caching with the Satellite servlet in tandem with modular page design to create a fast, efficient website.

How the Satellite Servlet Caches Pages

The Satellite servlet allows caching at the pagelet level. To implement caching with the Satellite servlet, you use Satellite Server XML or JSP tags in your WebCenter Sites pages, and you access pages using special Satellite URLs.

For example, suppose that you used the Satellite servlet to implement pagelet-level caching on a web page named myPage. As shown in Figure 5-2, this page is composed of a containing page and three pagelets; A, B, and C. The containing page and pagelets A and B are already cached on a Satellite Server system, but pagelet C is not cached.

Figure 5-2 Web Page Named myPage

Description of Figure 5-2 follows
Description of "Figure 5-2 Web Page Named myPage"

When a user requests myPage:

  1. Satellite Server examines the URL. If it is a Satellite URL, the Satellite servlet gets the cached copy of the containing page. The servlet then looks for pointers to pagelets which are not currently in its cache, and requests those pagelets from WebCenter Sites. So, in our example, the Satellite servlet gets the containing page, and gets pagelets A and B from its cache.

  2. The Satellite servlet requests Pagelet C from WebCenter Sites.

  3. WebCenter Sites parses the appropriate XML to create Pagelet C and sends it to the Satellite servlet.

  4. The Satellite servlet assembles Pagelets A, B, and C into the page, and sends the assembled page to the requester. The servlet also caches Pagelet C.

Implementing Caching with the Satellite Servlet

To implement pagelet-level caching with the Satellite servlet, you add Satellite tags to your WebCenter Sites templates. You do not develop any XML, JSP, or Java code on Satellite Server systems. In fact, Satellite Server does not know how to parse XML.

The Satellite tags in your elements are interpreted by the Java code you installed as part of Satellite Server. If this code is being called with a Satellite URL, it generates the information that the Satellite servlet uses to cache and construct the pagelets. If you do not call an element containing Satellite tags with a Satellite URL, the resulting page functions as if the Satellite tags were WebCenter Sites tags.

Satellite URLs look like the following example:

http://host_name:port/servlet/Satellite?pagename=page

where host_name and port are the hostname and port number of your Satellite Server computer, and page is the name of the page you are requesting. A Satellite URL can also include name/value pairs you want to pass to the called page.

Caching a Pagelet

The following sample code uses the render:satellitepage tag to call a pagelet. If the pagelet is not already in Satellite Server's cache, the Satellite servlet loads and caches the page. If the pagelet encounters an error during the processing and cannot be evaluated, it is not cached.

The render:satellitepage tag (and the satellite:page tag and their xml equivalents) identifies a cached pagelet by the pagename and name/value pairs passed to it. If the parameters or the name/value pairs differ from one invocation to another, a different pagelet will be cached, even if the content generated is the same. It is important to use name/value pairs to pass arguments to a pagelet through these tags.

Values passed through the ICS object pool, ICS List pool, page attribute context, and session (including session variables) may not be available to all called pagelets, because nested pagelets may not always be called at the same time as the parent. Furthermore, pagelets that rely on session or context data are rarely cacheable anyway, so attempting to cache them can result in non-deterministic behavior.

All parameters passed to a nested pagelet through render:satellitepage (and the satellite:page tag, and their xml equivalents) must be specified in the SiteCatalog as page criteria. This is WebCenter Sites's way of determining which parameters are relevant when building a pagelet for caching. Parameters other than those listed in the SiteCatalog are not permitted (an error indicating this will be written to the log).

<cs:ftcs>
<html>
  <body>
    <render:satellitepage pagename="My/Sample/Page" />
  </body>
</html>
</cs:ftcs>

Caching a Blob

Using Satellite tags to load and cache a blob is similar to the way you use Satellite tags to load and cache a pagelet. The following sample code adds to the previous example by calling a blob as well as a pagelet.

Line 7 uses the ics:selectto tag to perform a simple SQL query that retrieves a blob from the database. Results are returned in the form of an IList named imagelist.

Line 12 uses the satellite:blob tag to load the blob that was retrieved from the database. As with the satellite.page tag, if the blob is not in Satellite's cache, Satellite will load and cache the blob. The cachecontrol parameter is set so that the blob will expire at a given time; in this case, every 30 minutes.

  1. <html>

  2. <body>

  3. <!-- NOTE: This will fail if list has no content (== null) -->

  4. <ics:setvar name="category" value="logo"/>

  5. <ics:setvar name="errno" VALUE="0"/>

  6. <ics:selectto from="SmokeImage" list="imagelist" where="category" limit="1"/>

  7. <ics:then>

  8. <!-- Test a blob -->

  9. <render:satelliteblob service="img src"blobtable="SmokeImage" blobkey="id" blobwhere="imagelist.id" blobcol="urlpicture" blobheader="image/gif"cachecontrol="*:30:0 */*/*"alt="imagelist.alttext" border="0" />

  10. </ics:then>

  11. <render:satellitepage pagename="QA/Satellite/Functional/xml/"pagelet1"cachecontrol="never"/>

  12. </body>

  13. </html>

Never-Expiring Blobs

If there are binary files (or blobs) on your site that seldom change or never change, such as company logos, and you are using the Satellite servlet to cache at the pagelet level, you can improve performance by using an alternative method to serve these blobs.

To serve never-expiring blobs

  1. Copy the never-expiring images to all your Satellite Server hosts. Place them under the doc root for your web server.

  2. Access the images through <img src="pathname"> HTML tags rather than through satellite:blob Satellite tags.

For example, consider a never-expiring corporate logo file named CorporateLogo.gif. To use the alternative method of serving blobs, you would first copy the file to the web server's doc root on all your Satellite Server hosts. Then, instead of serving this logo through a satellite.blob tag, your element could simply use a tag like the following:

<img src="CorporateLogo.gif">

Note:

Be careful when using this mechanism for serving never-expiring images. For example, Satellite Server cannot warn you that one of the Satellite Server hosts does not contain the same image file as the other hosts.

http://myloadbalancer:1234/servlet/ContentServer?pagename=myPage

The expiration of the page is controlled by the expiration property. For more information on the expiration property, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.

5.3 Viewing the Contents of the Satellite Server Cache

The Inventory servlet lets you view the various items stored in the cache. You invoke the Inventory servlet by using the following URL:

http://host:port/servlet/Inventory?username=username&password=passwordword&detail=value

where:

Table 5-2 Inventory Servlet Parameters

Parameter Description

host:port (required)

The host name and port number of the Satellite Server host whose cache you want to view.

username (required)

The user name that you enter to log you in to the Satellite Server host.

password (required)

The password that you enter to log you in to the Satellite Server host.

detail (optional)

The type of information you wish the Inventory servlet to display. Valid values are:

  • names: Displays the header information, plus the page names of the pages in the cache.

  • keys: Displays the header information, plus the page names and keys of the items in the cache.

If you do not supply the detail parameter, or if you set its value to be anything other than name or keys, the header information displays.


The header contains the following information:

Table 5-3 Information Types

Information type Description

Remote host

The host that this Satellite Server system forwards requests to.

Maximum cache objects

The maximum number of items allowed in the cache.

Current size

The number of items currently in the cache.

Cache check interval

How often the cache is checked for expired items, in minutes.

Default cache expiration

The value of the expiration property.

Minimum file size (in bytes)

Items larger than this value are stored in files. Items smaller than this value are stored in RAM.


5.3.1 CacheManager

The WebCenter Sites CacheManager object maintains both the WebCenter Sites and Satellite Server caches. CacheManager can do the following:

  • Log pagelets in the cache tracking tables.

  • Keep a record of the content (assets) that pages and pagelets contain by recording cache dependency items in cache-tracking tables. Cache dependency items are items that, when changed, invalidate the cached pages and pagelets that contain them. A cache dependency item is logged as a dependency for the current page and all of that page's parent pages.

  • Remove pages and pagelets containing invalid items from the WebCenter Sites and Satellite Server caches.

  • Rebuild the WebCenter Sites and Satellite Server caches with updated pages and pagelets after the invalid pages have been removed.

5.3.2 The SiteCatalog Table

WebCenter Sites's SiteCatalog table lists the pages and pagelets generated by WebCenter Sites. An element must have an entry in the SiteCatalog table to be cached on WebCenter Sites and Satellite Server.

The fields in the SiteCatalog table set the default behavior of a WebCenter Sites page, including default caching behavior. For more information on the SiteCatalog table and its fields, see Section 23.4, "Creating Template Assets" and Section 23.6, "Creating SiteEntry Assets."

5.3.3 The Cache Key

Items stored in the WebCenter Sites and Satellite Server caches are given a name called a cache key. The cache key uniquely identifies each item in the cache. CacheManager locates items in the cache using the cache key. WebCenter Sites and Satellite Server generate cache keys automatically, based on the values in the pagename, resargs, and pagecriteria fields of the SiteCatalog table, and other internal data.

5.3.3.1 pagecriteria and the Cache Key

You include variables used by the page in the cache key by specifying them in a comma-separated list in the pagecriteria field of the SiteCatalog table. For example, suppose that you have a page called myPage which uses the values red and blue. To include red and blue in the myPage cache key, enter:

favoritecolor,second_favoritecolor in the pagecriteria column and favoritecolor=red&second_favoritecolor=blue in the resargsl column.

WebCenter Sites and Satellite Server use the pagecriteria and parameters that are passed to cached pages to help generate the cache keys. If the parameters differ from one invocation to another, a different page will be cached even if the content being generated is the same. For example:

http://mysatellite:1234/servlet/ContentServer?pagename=myPage&favoritecolor=red

calls a different page than:

http://mysatellite:1234/servlet/ContentServer?pagename=myPage&second_favoritecolor=blue

whether or not the content being generated is the same. Values passed in by the URL override values set in pagecriteria. For example, you have the myPage pagecriteria set to red,blue:

  • If the URL passes in a value of green, then green,blue (not red,blue) will go into myPage's cache key.

  • If the URL passes in values of green,violet, then green,violet (not red,blue) will go into myPage's cache key.

  • If the URL passes in values of green,violet,yellow, an error results.

If a page does not have pagecriteria set, the values in the resargs fields go into the cache key. As with pagecriteria, values passed in by a URL override values specified in the resargs fields.

5.3.4 Caching Properties

The default cache settings for WebCenter Sites and Satellite Server are contained in the futuretense.ini file. Additional Satellite Server properties are contained in satellite.properties. All properties can be modified by use of the Property Editor.

This section summarizes the WebCenter Sites and Satellite Server caching properties. For detailed information about the properties and the Property Editor, see the Oracle Fusion Middleware WebCenter Sites Property Files Reference.

5.3.4.1 WebCenter Sites Page Caching Properties

The following properties in futuretense.ini control disk caching on WebCenter Sites:

  • cs.pgCacheTimeout, which specifies the default timeout for pages in the WebCenter Sites cache.

  • cs.freezeCache, which controls whether the cache pruning thread should run to remove expired entries from the cache.

  • cs.nocache, which disables the entire WebCenter Sites page cache.

  • cc.SystemPageCacheTimeout, which specifies the number of minutes a cached page is held in memory.

  • cs.alwaysUseDisk, which specifies the default behavior for page entries in the SiteCatalog that have no cache override property specified.

  • cc.SystemPageCacheCSz, which specifies the maximum number of pages that can be cached in memory.

5.3.4.2 Satellite Server Properties

Satellite Server has two sets of properties (given in detail in the Oracle Fusion Middleware WebCenter Sites Property Files Reference):

  • One set of properties is in the futuretense.ini file on your WebCenter Sites system and includes the following:

    • satellite.page.cachecontrol.default, a deprecated property that specifies a default value for the cachecontrol parameter for the satellite.page, and RENDER.SATELLITEPAGE tags and their JSP equivalents.

    • satellite.blob.cachecontrol.default, which specifies a default value for the cachecontrol parameter for the satellite.blob, and RENDER.SATELLITEBLOB tags and their JSP equivalents.

  • The other set of properties is in the satellite.properties file on each Satellite Server host and comprises the following:

    • cache_folder: Specifies the directory into which Satellite Server will cache pagelets to disk.

    • file_size: Separates disk-cached pagelets and blobs from memory-cached pagelets and blobs according to the size that you specify.

    • expiration: Sets the default value for the length of time blobs stay in Satellite Server's cache.

    • cache_check_interval: Controls the frequency of the cache cleaner thread, and therefore when expired objects are pruned from cache.

    • cache_max: Specifies the maximum number of objects (pagelets and blobs) that can be cached (memory cache and disk cache combined) at a time.

5.4 Double-Buffered Caching

WebCenter Sites and Engage implement a double-buffered caching strategy, which uses the WebCenter Sites and Satellite Server caches in tandem on your live website. This double-buffered caching strategy ensures that pages are always kept in cache, either on WebCenter Sites or Satellite Server.

You can implement a similar caching strategy if you are running the WebCenter Sites core and Satellite Server without any of the other CS modules or products, by using the CacheManager Java API. For more information about the CacheManager Java API, see the Oracle Fusion Middleware WebCenter Sites Java API Reference.

Both the WebCenter Sites core and Satellite Server caches are maintained by WebCenter Sites's CacheManager object. CacheManager tracks when content changes by logging elements and the assets that those elements call in cache tracking tables.

When assets are updated and published, WebCenter Sites and Satellite Server caches are automatically flushed and updated in the following order:

Description of cs-ss1.gif follows
Description of the illustration cs-ss1.gif

  • Content providers publish updated assets to the delivery system. CacheManager checks the cache tracking tables to see which cached items are affected by the updated assets.

    Description of cs-ss2.gif follows
    Description of the illustration cs-ss2.gif

  • CacheManager flushes the outdated Page1 from the WebCenter Sites cache, then reloads the WebCenter Sites cache with the updated Page1.

    Any requests for Page1 will be served the old version of Page1 from the Satellite Server cache. This protects the WebCenter Sites computer from undue load as it deletes and rebuilds its cache.

    Description of cs-ss3.gif follows
    Description of the illustration cs-ss3.gif

  • CacheManager flushes the outdated items from the Satellite Server cache. As visitors come to the website and request Page1, the Satellite Server searches to see if Page1 is in its cache. Because Page1 is not in the Satellite Server cache, the request is passed on to WebCenter Sites.

    Description of cs-ss4.gif follows
    Description of the illustration cs-ss4.gif

  • The Satellite Server system's cache is filled with an updated version of Page1, taken from the WebCenter Sites cache. The updated page is served to the requestors. If Page1 were requested again, the page would be served from the Satellite Server cache.

5.4.1 Implementing Double-Buffered Caching

The first step in implementing double-buffered caching on your website is to design modular pages, as described in Section 5.1, "Modular Page Design." Once you have developed a modular page design, you implement a double-buffered caching strategy in three steps:

  • Develop a pagelet caching strategy

  • Set how individual pages and pagelets are cached by using the pagecriteria field of the SiteCatalog table

  • Code your elements with Satellite tags

5.4.1.1 Pagelet Caching Strategies

With a modular page design, caching occurs at the pagelet level; the containing page is never cached, so that any cached pagelets are always protected by ACLs. You choose which pagelets get cached based on how frequently they are updated.

The following table summarizes the guidelines for caching pagelets:

Table 5-4 Guidelines for Caching Pagelets

Cache a Pagelet Don't Cache a Pagelet
  • If the content seldom changes.

  • If the pagelet does not contain logic that requires evaluation to work.

  • If the content changes frequently.

  • If the content must be "real time."

  • If the pagelet contains code that checks for ACLs, or other logic that requires evaluation to work.


The following diagram is an example of a modular page:

The containing page should never be cached; this lets you put logic, which requires evaluation by WebCenter Sites, into your pages, while still gaining the performance benefits of caching. It also allows your page to be protected by WebCenter Sites ACLs.

The header and footer pagelets in this example should be disk cached. They rarely gets updated, and should be designed accordingly. The header and footer may be static HTML written into your template, or disk-cached content from WebCenter Sites.

The sidebar is also a good candidate for disk caching. It has a small number of variations, and its content is determined by a small number of parameters.

Determining how to cache the body pagelet is more complex. The contents of the body pagelet probably depend on where the website visitor is in the site. There are three possible types of content for the body pagelet:

  • The results of a search that the website visitor runs

  • The results of a frequently run query

  • An article

Your caching strategy should be as follows:

  • If the content of the body pagelet is the result of a search based on parameters that the website visitor enters, you do not want to cache it. Such pages change for each visitor, and there is little benefit to caching them.

  • If the content is the product of a standard query that visitors often use, you should use resultset caching. Caching frequently run queries in the memory cache improves performance. For more information on resultset caching, see Chapter 14, "Resultset Caching and Queries."

  • If the content of the body pagelet is the text of an article, you should cache the pagelet to disk.

5.4.2 Setting cscacheinfo

The values in the cscacheinfo field of the SiteCatalog table allow you to control how pages get cached on WebCenter Sites on a page-by-page basis.

You can change these properties for each page and pagelet in your website. For example, if you want a containing page element to be uncached on WebCenter Sites, set the values in cscacheinfo to false.

For more information on the cscacheinfo field, see Section 23.4, "Creating Template Assets."

5.4.3 Coding for Caching

To implement double-buffered caching, you code your elements with Satellite Server tags. If you are running WebCenter Sites and Satellite Server only, use the Satellite tags documented in the Satellite Server sections of the Oracle Fusion Middleware WebCenter Sites Tag Reference.

Automatic cache maintenance is dependent upon logging your assets in the cache tracking tables. If you use the ASSET.LOAD tag to load an asset, that asset is automatically logged in the cache tracking tables. For those sections where ASSET.LOAD is not used, use the RENDER.LOGDEP tag to log content in the cache tracking tables.

Note:

Cache dependencies are logged only if a page or pagelet is cached on WebCenter Sites. If a page is uncached on WebCenter Sites but cached on Satellite Server, that page will not be automatically flushed from the cache when its content is updated.

5.4.4 Caching and Security

Cached pagelets require special security considerations as you design your site and develop your caching strategy. The following sections outline security considerations for pages cached in the WebCenter Sites and Satellite Server caches.

5.4.4.1 WebCenter Sites Security

Pagelets that are disk cached on WebCenter Sites are bound by WebCenter Sites's ACLs, allowing you to use those ACLs to prevent unauthorized access to a page.

Note, however, that although WebCenter Sites checks the ACL of a containing page, it does not check the ACLs of the pagelets that the containing page calls. For example, suppose that your site uses three ACLs: Open, Secret, and TopSecret. Your containing page can be viewed by members of the Open ACL, but it calls pagelets that should be viewed only by members of the Secret and TopSecret ACLs. Because WebCenter Sites only checks a visitor's ACL of the containing page, visitors with the Open ACL can view content meant for members of the Secret and TopSecret ACLs.

To ensure that all the relevant ACLs are checked

  1. Include the ACL for the page that you want to protect in that page's cache criteria, as shown in the following sample code:

    <render.satellitepage pagename="innerwrapper" userAcl="SessionVariables.member" c="Article" cid="123">
    
  2. In the pagelet, insert code to check the ACLs, as shown in the following sample:

    <asset.load name="art" type="Variables.c" OBJECTID="Variables.cid"/> 
    <ASSET.GET NAME="art" FIELD="myACL"/> <!-- note you need a column in your db to support this --> 
    <IF COND="Variables.userACL=Variables.myACL"> 
    <THEN> 
    <render.satellitepage pagename="protected_art_tmpl1" c="Variables.c" cid="Variables.cid"/> 
    </THEN> 
    <ELSE> 
    <render.satellitepage pagename="accessDenied"/> 
    </ELSE> 
    </IF>
    

5.4.4.2 Satellite Server Security

Pagelets that will be cached on Satellite Server are bound only by WebCenter Sites ACLs under the following circumstances:

  • If they are retrieved from the WebCenter Sites cache

  • If they must be generated by WebCenter Sites to fulfill the page request

If a pagelet is served from the Satellite Server cache, it is no longer protected by WebCenter Sites ACLs.

To ensure that the content of your Satellite Server pages is secure, never cache your containing page and be sure that you put an ACL checking mechanism in the uncached container.

If your elements are coded with Satellite tags but you do not yet have
Satellite Server installed, the page design considerations outlined in Section 5.4.4.1, "WebCenter Sites Security" apply to you. Once Satellite Server is installed, however, WebCenter Sites checks the ACLs of uncached pagelets called from a containing page. The ACLs of pagelets cached on Satellite Server are not checked.