At present when users don't use the Authentication Module, they can use a $_SERVER variable instead. We're using this at UM-Dearborn because we'd rather our users authenticate using the campus' Weblogin than manage a second login stored in CORAL. It appears, though, that there's a presumption in the Organizations and Resources modules that if users can authenticate into the page it must be okay for them to have at least Read-Only access; a comment in the setuser.php:25 file for each module describes this assumption:
//if the user doesn't exist in database set them up with shell user account (we assume that since they were authorized to come in they can create new requests and view existing)
This behavior is different from the licensing and usage modules, which instead directs users to not_available.php if they aren't authorized to access the module even when using local authentication. Generally, it would be nice for the Resources and Organizations modules to also have this option because, while the accounts are read-only, administrative login information is held there.
I wanted to officially recommend that there be a setting in each module allowing users to decide whether shell accounts are created for that module or if unauthorized users are just blocked automatically, and to code that option into the user.php file. This would help lay the groundwork for a consistent experience across the modules rather than have CORAL create shell accounts for some modules and block unauthorized users from others, without any opportunity to configure which is which.
At present when users don't use the Authentication Module, they can use a $_SERVER variable instead. We're using this at UM-Dearborn because we'd rather our users authenticate using the campus' Weblogin than manage a second login stored in CORAL. It appears, though, that there's a presumption in the Organizations and Resources modules that if users can authenticate into the page it must be okay for them to have at least Read-Only access; a comment in the setuser.php:25 file for each module describes this assumption:
//if the user doesn't exist in database set them up with shell user account (we assume that since they were authorized to come in they can create new requests and view existing)This behavior is different from the licensing and usage modules, which instead directs users to not_available.php if they aren't authorized to access the module even when using local authentication. Generally, it would be nice for the Resources and Organizations modules to also have this option because, while the accounts are read-only, administrative login information is held there.
I wanted to officially recommend that there be a setting in each module allowing users to decide whether shell accounts are created for that module or if unauthorized users are just blocked automatically, and to code that option into the user.php file. This would help lay the groundwork for a consistent experience across the modules rather than have CORAL create shell accounts for some modules and block unauthorized users from others, without any opportunity to configure which is which.