Index: openacs-4/packages/acs-core-docs/www/ext-auth-requirements.adp =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/ext-auth-requirements.adp,v diff -u -r1.6.2.9 -r1.6.2.10 --- openacs-4/packages/acs-core-docs/www/ext-auth-requirements.adp 27 Apr 2022 16:52:19 -0000 1.6.2.9 +++ openacs-4/packages/acs-core-docs/www/ext-auth-requirements.adp 13 Jul 2023 12:43:19 -0000 1.6.2.10 @@ -1,18 +1,18 @@ -{/doc/acs-core-docs {ACS Core Documentation}} {External Authentication Requirements} +{/doc/acs-core-docs/ {ACS Core Documentation}} {External Authentication Requirements} External Authentication Requirements

External Authentication Requirements

-Vision

People have plenty of usernames and passwords already, we +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 other system.

Besides, administrators have better things to do than create @@ -74,7 +74,7 @@

Requirements

-New API

+New API
@@ -207,7 +207,7 @@ to access these settings.

OpenACS will come pre-configured with one authority, which is the "local" authority, meaning we'll authenticate as normal using the local users table. This will, just like any other -authority, be implemetned using a service contract.

+authority, be implemented using a service contract.

Synchronizing and Linking @@ -383,7 +383,7 @@ mode.

Similarly, ad_conn user_id will continue 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 +ad_conn untrusted_user_id, which will be set to the user_id for all login levels.

This should ensure that we get full access to the new feature, while leaving all current code just as secure as it was before.

@@ -672,8 +672,8 @@
\ No newline at end of file
FeatureStatusDescription
New API