Active Directory and @LOGNAME:

In my experience so much depends on the value of the user ID (@LOGNAME). Security and access are frequently assigned by user IDs. Even the initial interaction with a logged in user can depend on the user ID (I'm referring to how in Pick mode if there is a VOC item record ID that is the same as the user ID then that will be executed (if it is a sentence, paragraph, verb, remote, or Proc) before the VOC "LOGIN" item.)

The problem arises when users authenticate with Active Directory (instead of the passwd file) and web based UIs will accept any combination of uppercase and lowercase letters for the user ID. Users accustomed to having access to menu items and to update records may be surprised when the system presents a strange menu, does not allow access, or displays information in read-only mode (or all three). Users authenticating from a different domain will introduce another component to the mix by having the domain included in the @LOGNAME variable  (e.g. Domain/userID).

If the application security and/or access uses either all uppercase or all lowercase user IDs then one quick fix is to overwrite the @LOGNAME variable early in the process, prior to having security checked and access given. Below is a very small program to check if @LOGNAME is all lowercase and if not initializes it to all lowercase letters:

Note: All programming displayed on this site is for illustrative purposes only. Use at your own risk.

---

$options internal
*
* Overwrite the @LOGNAME with all lowercase if it is mixed case...
*
if @LOGNAME <> OCONV(@LOGNAME,"MCL") then
   new.logname = OCONV(@LOGNAME,"MCL")
   @LOGNAME = new.logname
   SWAP @LOGNAME, new.logname
end

end

---