Next, the Request Processor examines the request for session information. Session information is generally sent from the client -(the user's browser) to the server via cookies. The security/session -handler is described in detail in its own document. It examines -the client request and either extracts or sets up new session -tokens for the user.
Next, the Request Processor checks if the user has appropriate +(the user's browser) to the server via cookies. The security/session handler is described in +detail in its own document. It examines the client request and +either extracts or sets up new session tokens for the user.
Next, the Request Processor checks if the user has appropriate access privileges to the requested part of the site. In OpenACS 5.9.0, access control is dictated by the permissions system. In this case, -the RP checks if the user has "read" priviledges on the object in -the site map specified by the URL. This object is typically a -package instance, but it could easily be something more granular, -such as whehter the user can view a particular piece of content -within a package instance. This automatic check makes it easy to -set up sites with areas that are only accessible to specific groups -of users.
Finally, the Request Processor finds the file we intend to
serve, searching the filesystem to locate the actual file that
corresponds to an abstract URL. It searches for files with
predefined "magic" extensions, i.e. files that end with:
-.html, .tcl and .adp.
If the RP can't find any matching files with the expected
+.html, .tcl and .adp.
If the RP can't find any matching files with the expected
extensions, it will look for virtual-url-handler files, or
.vuh files. A .vuh file will be executed as if it were a
Tcl file, but with the tail end of the URL removed. This allows the
code in the .vuh file to act
like a registered procedure for an entire subtree of the URL
namespace. Thus a .vuh file can
be thought of as a replacement for filters and registered procs,
-except that they integrate cleanly and correctly with the RP's URL
-mapping mechanisms. The details of how to use these files are
+except that they integrate cleanly and correctly with the RP's
+URL mapping mechanisms. The details of how to use these files are
described in OpenACS 4 Request Processor
Design.
Once the appropriate file is found, it is either served directly -if it's static content, or sent to the template system or the -standard Tcl interpreter if it's a dynamic page.
+if it's static content, or sent to the template system or the +standard Tcl interpreter if it's a dynamic page.Once the flow of control reaches a dynamic page, the Request
Processor has populated the environment of the request with several
-pieces of useful information. The RP's environment is accessible
-through the ad_conn interface,
-and the following calls should be useful to you when developing
-dynamic pages:
ad_conn
+interface, and the following calls should be useful to you when
+developing dynamic pages:[ad_conn
user_id]The ID of the user associated with this request. By convention this is zero if there is no user.
[ad_conn
@@ -107,8 +106,8 @@
name of the package.[ad_conn
path_info]In a .vuh file, path_info is the trailing part of the URL not
matched by the .vuh file.