Signing XPages

XPages are signed with the ID of the current Domino® Designer user upon saving the XPage design element, and/or upon generating its implementation (i.e .class) file(s).

About this task

Signing an XPage determines whether it will load at runtime, and thereafter whether it can run with or without restrictions on its methods and operations. Running with restrictions excludes certain features such as file or network I/O, which is the more common approach. Running without restrictions allows all supported features of the XPage implementation languages to be used (see topic Restricted LotusScript® and Java agent operations at Domino® Designer Basic User Guide and Reference > Application Design > Adding automation to applications).

As server access rights, the rights to execute restricted/unrestricted methods are assigned to specific signers or groups in the Programmability Restrictions section of the server document Security tab (see topic Controlling agents and XPages that run on a server at Domino® Administrator Help > Security > Server access for Notes® users, Internet users, and Domino® servers > Customizing access to a Domino® server).

When an XPage is invoked (as for Agents), Domino® checks the server document for the server security rights of the XPage signer, in addition to checking access rights for the authenticated Web user. For components of the XPage (e.g. included XPages, custom controls, JSF extensions, or server JavaScript libraries), Domino® checks each component signer’s server access rights, and if indicated, downgrades the XPage session to execute only with restrictions (if set for Domino®, the NoExternalApps notes.ini variable has the same effect). At runtime, signatures for DDE users without any server rights to sign XPages at all will generate HTTP 403 errors back to the browser.