Feature Request: Support for SwiftDialog 2.5.0 Login Window Context

[PinkShellos]

Computer labs and shared resource computers often need to be redeployed without a user logged in to have them provisioned before a user needs it.

SwiftDialog 2.5.0 added support for a --loginwindow flag that can be executed by a LaunchDaemon to enable this functionality.

I propose setting up a ShowAtLoginWindow key that validates SwiftDialog 2.5.0 or newer is installed, skips the logged in user check, and runs SwiftDialog with the --loginwindow flag.

[BigMacAdmin]

This is definitely something I plan to add, but likely will be a few more weeks before I am able to put engineering time to it

[PinkShellos]

I'm working on a PR for it at the moment. I'm just trying to find the right place to put it in the code so it makes sense and doesn't overcomplicate the existing code.

Currently, the I have a check inside wait_for_user as well as a separate check function below the implementation of it to add into the arguments.

I haven't done any testing of it, but I'll push the PR once I have something that looks workable for folks to try out.

[BigMacAdmin]

I recommend the following:
Create a new function that checks for the true boolean in the configuration file. Lets call it check_run_at_loginwindow

If that option is set to true you can change the function wait_for_user to contain the code you want it to contain in order to run at login window. Then you don't have to worry about later "if/then" statements, we always just run the wait_for_user function at the appropriate time and it either actually waits for the user or runs the new "run at loginwindow" code.

We may also want to find/replace (carefully) the name of the wait_for_user function so that it makes more sense now. Something like loginwindow_action

We need to also be careful this doesn't step on the silent_mode options, because that already changes wait_for_user and silent mode should supercede the new run at loginwindow functionality.

[PinkShellos]

Wanted to run this potential solution by you to see how you felt about it:

function check_run_at_loginwindow(){
    showAtLoginWindowSetting=$($pBuddy -c "Print ShowAtLoginWindow" "$BaselineConfig")
    if [ "$showAtLoginWindowSetting" = "true" ]; then
        showAtLoginWindow="true"
    else
        showAtLoginWindow="false"
    fi
}

I then decided to better preserve your original code by using a case statement:

function loginwindow_action(){
    # default loginwindow setting to false, change if true
    showAtLoginWindow="false"
    check_run_at_loginwindow
    case "$showAtLoginWindow" in
    "true")
    debug_message "Baseline has been set to run at loginwindow, skip verified user check.";;
    "false" | *)
        #Set our test to false
        verifiedUser="false"
        #Loop until user is found
        while [ "$verifiedUser" = "false" ]; do
            #Get currently logged in user
            currentUser=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }' )
            else      #Verify the current user is not root, loginwindow, or _mbsetupuser
                if [ "$currentUser" = "root" ] \
                    || [ "$currentUser" = "loginwindow" ] \
                    || [ "$currentUser" = "_mbsetupuser" ] \
                    || [ -z "$currentUser" ]
                then
                #If we aren't verified yet, wait 1 second and try again
                sleep 1
                else
                    #Logged in user found, but continue the loop until Dock and Finder processes are running
                    if pgrep -q "dock" && pgrep -q "Finder"; then
                        uid=$(id -u "$currentUser")
                        log_message "Verified User is logged in: $currentUser UID: $uid"
                        verifiedUser="true"
                    fi
                fi
            fi
        debug_message "Disabling verbose output to prevent logspam while waiting for user at timestamp: $(date +%s)"
        set +x
        done
        debug_message "Re-enabling verbose output after finding user at timestamp: $(date +%s)";;
    esac
}

I used a find/replace to swap wait_for_user with loginwindow_action as well. I'm updating the PR with these commits now, but let me know what you think.

[BigMacAdmin]

I am good with this format, however, it does not appear that this accounts for --silent mode, which also needs to skip the wait_for_user function

[BigMacAdmin]

Perhaps we need to think of this more like "Run mode"

Is the "Run mode" "Original Flavor, Silent, or LoginWindow" ? What do you think?

If so, --silent should override any other mode that may also be configured

[PinkShellos]

That actually makes way more sense to treat it as such. So then you could just call --loginwindow as an argument and then we don't need to modify the existing codebase. I'm going to retract the PR for now and revert my changes so I can start fresh.

[BigMacAdmin]

I've been thinking on this.

I think the goal needs to be: Determine which runmode we have by reading all of the relevant configuration profile keys, then at the step where wait_for_user is running we instead run a function like initiate_runmode.

So read the config to see if silent is there, read the config to see if runatloginwindow is there (also read the command line arguments for both)

Then do one if/elif statement:

• If silent mode is enabled, create the initiate_runmode(){} function with what we want to happen for silent mode
• Elif runatloginwindow mode is enabled: create the initiate_runmode(){} function with what we want to happen for loginwindow mode
• else (if neither silent or runatloginwindow are set) then initiate_runmode(){} basically gets the current wait_for_user code

What do you think?

[PinkShellos]

I rebased from main instead of dev, hopefully that doesn't cause issues with the PR. I did submit the PR to dev.

[BigMacAdmin]

Thats awesome, I look forward to reviewing when I am able.

I don't have any changes in the works in the dev branch, so i think I can point the PR to the right place when needed.

Thank you for your contribution!