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_
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
