Everyone, As an adjunct to this conversation, there has come up again a topic that is asked about periodically -
What does the Disable mean on the User form for a user. Well, out of the box, it doesn't mean anything. We always are considering what it should mean, but a bit part of the discussion is what does it mean in conjunction with AREA and external authentication. If a user is disabled, should they fail in an AREA authentication? Or do they succeed. If they succeed, do we still add on permissions from the user record (cross-reference-blank-password) or do we authenticate them but not authorize them (confusing). Or, do we just let them succeed and attach permissions or whatever that is cross-referenced but if you chain AREA and ARS, we would be OK with AREA but not if that didn't pass and we moved to (chained to) ARS for authentication. Anyway, for those who want to make the disable operation be meaningful, there is a simple workflow technique you can use. To offer a complete solution, we are talking about 3 or 4 filters. This would be for handling ARS validation - essentially using the 3rd option above for AREA, if the user validates with AREA, it is OK and any information on the AR System user record that is cross referenced is used - but we would not pass any authentication that is chained to ARS. OK, the filters: Disable an existing user Filter that fires on Modify with a run if of TR.Status = "Disabled". Action is to perform a Direct SQL command to update the password in the user_cache table to INVALID Update user_cache SET (password = 'INVALID') WHERE entryId = '$1$' entry ID is the key we link by although you could also user username = '$101$' as well to set for matching user name. Either would work. Yes, the word INVALID. This is the same value we put in the password field of the user_cache record when a user is blocked for too many bad password attempts. This user can NEVER login unless his password is reset by someone else as they cannot login to change it. (depending on your DB as some DBs want parenthesis around the set clause and others do not if there is only one item in the clause) Prevent work on a disabled user Filter that if Status = "Disabled" and Password != $NULL$ will return an error that you cannot change the password of a disabled user. Or you could block all change to a disabled user or do whatever you want here to prevent a password change for a disabled user which would then reset the password and reactivate them. Reactivate a disabled user Filter that if TR.Status = "Enabled" and DB.Status = "Disabled" will run check that there is a password specified (must change password on enable) and that if you are using the user password feature you set the option to require the user to change password on first login for this user so that they have to change after login as their password is known by someone else. Create a disabled user Now if you want to create a disabled user, there is a bit more effort. The problem is that the user_cache entry doesn't exist for you to modify as the User record is being created. You could just disallow Status = Disabled on Create/Merge. Argument is why are you creating disabled users? Of if you want to, you need to do something to disable the user right after create (phase 3 run process that comes back and updates the user_cache entry after it is there or something similar). Whether we add this or not is under discussion, but it is clearly something you can do on your own system if desired. I just wanted to get a solution out there for folks who wanted to do something in this area. I hope this is useful, Doug Mueller _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
