I have some workflow that uses this Run Process when a (knowledgeable) user wanders from the forms they should be accessing. I originally built in it on 7.6.04 but has since been upgraded to 8.1. Works very well.
Jason On Mon, Feb 3, 2014 at 12:48 PM, L G Robinson <[email protected]> wrote: > ** > Hi Doug, > > Thanks for this post... I have been looking for this "secret" for some > time. As I was implementing my solution, I ran across this Process: > > Application-Invalidate-User > > Is there any reason to use the explicit direct SQL instead of calling the > above Process? Perhaps this process was a recent addition? I am running ARS > 7.6.04 and it appears to do exactly the same thing as the suggested SQL, at > least as far as I can tell from my logs. > > Thanks. > Larry > > On Fri, Jan 31, 2014 at 3:59 PM, Mueller, Doug <[email protected]>wrote: > >> ** >> >> 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 3rdoption >> 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 >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
