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.