Question

Alright guys, so I have a script set up to turn off the “require password on wake” function when I am at home. It pings my phone to see if I am connected to the network, and if not turns on lock to wake. So:

try
do shell script "ping -c2 X.X.X.X"
set theResult to the result
if theResult contains " 2 packets received," then
    tell application "System Events"
        tell security preferences
            get properties
            set properties to {require password to wake:false, require password to unlock:false}
        end tell
    end tell
end if
on error
tell application "System Events"
    tell security preferences
        get properties
        set properties to {require password to wake:true, require password to unlock:true}
    end tell
end tell
end try
end

This works just fine, however it asks to authenticate. I don’t really want to use the enter text & return route, nor the clipboard route, because I don’t want the password in the script… so is there a way to avoid the authentication?

Answer 1

If your goal is to enable/disable “password on wake” rather than to run that particular script without authentication, use either

tell application "System Events"
    set require password to wake of security preferences to true
end tell

or

do shell script "defaults write com.apple.screensaver -int 1"

and the same with “to false” and “-int 0” to turn the setting off. None of these require authentication, as they’re simply changing a user-level preference (stored in

~/Library/Preferences/com.apple.screensaver.plist

on my system, though this is an implementation detail you shouldn’t rely on).

What triggers the authentication dialog in your script is the other property, “require password to unlock”, equivalent to the “Require an administrator password to access locked preferences” option in the “Advanced…” part of Security Preferences. Under the hood, this option is equivalent to changing a number of settings in the Authorization Services database,

/private/etc/authorization

controlling whether various system-wide preferences may be left unlocked for unauthenticated changes.

System Events does appear to have a (less serious) bug, however: on my systems, setting “require password to unlock” has no effect, whether I authenticate as an admin or not.