Index: openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html,v diff -u -r1.44 -r1.45 --- openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 28 Mar 2018 21:55:34 -0000 1.44 +++ openacs-4/packages/acs-core-docs/www/ext-auth-requirements.html 25 Apr 2018 08:38:27 -0000 1.45 @@ -1,7 +1,7 @@ External Authentication Requirements
Alex logo
Prev Chapter 15. Kernel Documentation Next

External Authentication Requirements

-

Vision

+

Vision

People have plenty of usernames and passwords already, we don't want them to have yet another. We want people to be able to log in to OpenACS with the same password they use to log in to any @@ -72,7 +72,7 @@

Requirements

-

New API

+

New API

@@ -147,7 +147,7 @@ either already be in the users table through a batch synchronization job, or that the relevant authentication implementation supports real-time synchronization of user data. -Specifically, if you want remote users who haven't yet logged in to +Specifically, if you want remote users who haven't yet logged-in to OpenACS to show up in user searches, you'll have to do the batch synchronization.

All in all, the login box will be an includeable template and @@ -451,16 +451,16 @@

I like the idea of having multiple login levels:

-

  1. Not logged in

  2. Untrusted login: We'll show you un-sensitive personal +

    1. Not logged-in

    2. Untrusted login: We'll show you un-sensitive personal content, but won't let you modify anything or see personal data. A normal login becomes untrusted after a certain amount of time, and the user will have to re-enter his/her password in order to gain access to personal data. Untrusted login never expires, unless explicitly done so through either changing password or clicking a - special "expire all logins" link.

    3. Normal login: The user is logged, and has type his + special "expire all logins" link.

    4. Normal login: The user is logged-in, and has type his password sufficiently recently that we trust the login. All normal operations are allowed. Will degrade to untrusted login after a - specified amount of time.

    5. Secure login: The user is logged in over a secure + specified amount of time.

    6. Secure login: The user is logged-in over a secure connection (HTTPS), potentially even using a special secure password. This would be for sensitive actions, such as credit card transactions.

    @@ -480,13 +480,13 @@ even more feasible to have a more secure login expiration setting.

    By default, auth::require_login would -bounce to the login page if the user is only logged in at the +bounce to the login page if the user is only logged-in at the untrusted level. Only if you explicitly say auth::require_login -untrusted will we give you -the user_id of a user who's only logged in in untrusted +the user_id of a user who's only logged-in in untrusted mode.

    Similarly, ad_conn user_id will continue -to return 0 (not logged in) when the user is only logged in +to return 0 (not logged-in) when the user is only logged-in untrusted, and we'll supply another variable, ad_conn untrusted_user_id, which wlll be set to the user_id for all login levels.

    @@ -555,10 +555,10 @@

Currently, if you've ever left a permanent login cookie on -someone elses machine, that person will be forever logged in until +someone elses machine, that person will be forever logged-in until he/she explicitly logs out. You can change your password, you can do anything you want, but unless a logout is requested from that -particular browser, that browser will be logged in forever.

+particular browser, that browser will be logged-in forever.

I want to change our session handling code so that old login cookies can be expired. This would be done automatically whenever you change your password, and we could also offer a link which does