Index: openacs-4/packages/acs-core-docs/www/security-design.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/security-design.adp,v diff -u -r1.4 -r1.5 --- openacs-4/packages/acs-core-docs/www/security-design.adp 25 Apr 2018 08:38:28 -0000 1.4 +++ openacs-4/packages/acs-core-docs/www/security-design.adp 3 Sep 2024 15:37:32 -0000 1.5 @@ -1,16 +1,22 @@ -{/doc/acs-core-docs {ACS Core Documentation}} {Security Design} +{/doc/acs-core-docs/ {ACS Core Documentation}} {Security Design} Security Design +

-Security Design

<authorblurb>

By Richard Li and Archit -Shah

</authorblurb>
+Security Design
+

By Richard Li and Archit Shah

+OpenACS docs are written by the named authors, and may be edited by +OpenACS documentation staff.
@@ -62,7 +68,7 @@ reauthenticate themselves over SSL when performing some action that requires secure authentication.

Although this makes the site less user friendly, this design significantly increases the security of the system because this -insures that the authentication tokens presented to a secure +ensures that the authentication tokens presented to a secure section of the web site were not sniffed. The system is not entirely secure, since the actual authentication password can be sniffed from the system, after which the sniffer can apply for a @@ -204,7 +210,7 @@ Session Creation

The creation and setup of sessions is handled in sec_setup_session, which is called either to create a new session from sec_handler or from ad_user_login when there is a change in authorization level. The session management code must do two -things: insure that session-level data does not float between +things: ensure that session-level data does not float between users, and update the users table which has columns for n_sessions, last_visit, and second_to_last_visit.

If there is no session already setup on this hit, a new session is created. This happens when sec_setup_session is called from @@ -213,8 +219,8 @@ the current session is continued, simply with a higher authorization state. This allows for data associated with a session to be carried over when a user logs in.

The users table is updated by sec_update_user_session_info which is -called when an existing session is assigned a non-zero user_id, or -when a session is created with a non-zero user_id.

+called when an existing session is assigned a nonzero user_id, or +when a session is created with a nonzero user_id.

Passwords

@@ -249,7 +255,7 @@ obtain the constant value of a given parameter; these values are used to dynamically generate a procedure that returns a constant. This approach avoids (relatively) expensive calls to ad_parameter in sec_handler. The impact of this approach is -that these parameters cannot be dynamically changed at runtime and +that these parameters cannot be dynamically changed at run time and require a server restart.

@@ -493,7 +499,7 @@ nice to expand the interface to allow for more persistent properties. In the past, there was a sec_browser_properties table that held permanent properties about each unique visitor (for -logged in users, these are just user properties). This was +logged-in users, these are just user properties). This was unscalable because there was no way to delete these properties, and the table tended to grow to millions of rows. It would be nice to view browser and session properties as two types of client @@ -516,7 +522,7 @@

Cookieless Sessions

Two trends drive the requirement for removing cookie dependence. -WAP browsers that do not have cookies, and publc perceptions of +WAP browsers that do not have cookies, and public perceptions of cookies as an invasion of privacy. The rely on the cookies mechanism in HTTP to distinguish one request from the next, and we trust it to force requests from the same client to carry the same