What is best practice for identifying the user with queued jobs

I'm going to have to move some of my background tasks to Queues and I was looking into a solution like that for when I have to implement it. What I decided to try is to pass the User ID to the queue, and then have the queue handler Set the authorized user by the ID using the following

$userId; // Passed when I queued the job
Auth::loginUsingId($userId);

I am hoping this will essentially make all my Auth::user() requests work fine without having to refactor code. Maybe give that a shot and see how it works.

@BENderIsGr8te I should have included a code sample but thats actually what solution 2 is. Are there any pitfalls with this method? It's certainly much easier that the alternative.

@rdelorier it's apparent that I can't read because I must have fallen asleep before I finished reading your book ;)

I wouldn't think there would be any pitfalls as long as you don't get numerous errors when testing. The User is just set in a session variable. Assuming that Jobs/Commands/Queues still have access to session variables then it should work fine as long as you aren't trying to get the users URL or IP address or anything funky like that.

Maybe someone that has more experience with Queues that has dealt with this issue has a better solution, but I would be surprised if your Solution #2 wasn't the exact solution because I really can't think of that many use cases for Auth::loginUsingId().

Why wouldn't you just pass the $userId as a variable to the queue? Why are they protected by Auth middleware? Perhaps I'm missing something...

There is no middleware here. The Auth::user() method is being used throughout his project to get the logged in user to perform various tasks. As he is moving some of these time consuming tasks to queued jobs, he is trying to avoid re-writing all his methods. He is trying to find out if using Auth::user() to get the current user (while all the time, mocking the current user) is going to cause him issues throughout his project.

A queued job has no notion of session or login. This is a non-sense.

If you need an user in a queued job, just pass it the user or the user id.

I will have to agree with @pmall here. The queue shouldn't be using sessions, rather it should just be handed the user id so it can update what needs to be updated. If it requires a restructuring of a bit of code, I would say it's for the better in the long run, since this is probably an indication of your code being tighly coupled with Laravel's Guard.

@pmall It's not necessarily the queued job that needs the user. Say the user changes the tasks required, I need to examine all open jobs (no limit to how many there may be) and add/remove required tasks. Removing/Adding a task to/from a job could cause the job status to change which fires and event that creates an activity "{Auth::user()->name} has completed {$job->id}", Are you saying its inappropriate for my model events to request the current user from Auth and I should instead find another way to tell the model which user is updating it?

@cbojer You are certainly correct about by code being highly dependent on Laravels Guard but I cannot see myself ever trying to move to another framework and assumed it was acceptable. Should Guard not be used outside of http requests?

@BENderIsGr8te I agree that there aren't many other use cases for loginUsingId and using this method was quick and easy, I updated all jobs to be queued and tested with this solution without and further issues. I think I'll stick with this until I have an issue pop up.

Thank you all for taking the time to read and reply.

@pmall I think you're misunderstanding, I'm not using auth to get the user in the job, I'm using auth to get the user in other parts of the app that are triggered by the queued job and have absolutely no idea that the job even exists. You say its non-sense to use auth to mock the logged in user where I feel like its non-sense to ignore an integral part of the framework simply because I queued the job instead of completing it within the users request.

I'm using auth to get the user in other parts of the app that are triggered by the queued job and have absolutely no idea that the job even exists.

I'm curious to see this job's code :)

class JobSettingsHandler implements  ShouldBeQueued{

    /** @var ValidatorProvider */
    private $provider;

    /** @var Guard  */
    private $auth;

    private $requiredValidators = [];

    /**
     * Create the event handler.
     *
     * @param ValidatorProvider $provider
     */
    public function __construct(ValidatorProvider $provider, Guard $auth)
    {
        $this->provider = $provider;
        $this->auth = $auth;
    }

    /**
     * Handle the event.
     *
     * @param  AccountSettingsUpdated  $event
     * @return void
     */
    public function handle(AccountSettingsUpdated $event)
    {
        $this->auth->loginUsingId($event->userId);
        $this->removeOrphandedValidators($event);
        $this->requiredValidators = $this->provider->validationRequired($event->jobTypes);

        $query = Job::whereAccountId($event->accountId)
            ->whereIn('job_type', $event->jobTypes)
            ->open();

        //bite size chunks
        $query->chunk(1000, function(Collection $jobs){
//          dd($jobs);
            foreach($jobs as $job){
                $job->updateStatus(true);
            }
        });
    }


    /**
     * Find an remove all job validations that are no longer needed
     * @param AccountSettingsUpdated $event
     */
    private function removeOrphandedValidators(AccountSettingsUpdated $event)
    {
        foreach($this->provider->validationRequired() as $jobType => $requirements){
            //delete the validators where job type = $jobType and validation not in required
            $query = JobValidation::whereHas('job', function($query) use ($event, $jobType, $requirements)
            {
                //Filter by account
                $query->byAccountId($event->accountId);

                //Only open jobs
                $query->open();

                /*
                 * include only validators where the job type does
                 * not require the validator type
                 */
                $i = 0;

                $query->where(function($query) use ($jobType, $requirements) {
                    $query->where('jobs.job_type', '=', $jobType)
                        ->whereNotIn('job_validations.validatable_type', $this->getQualifiedNames($requirements));
                });
            });

            //We need to call delete on the model so it can do its own cleanup
            //otherwise we could replace chunk with delete
            $query->chunk(100, function(Collection $validators){
                $validators->each(function($v){ $v->delete(); });
            });
        }
    }

    /**
     * Transforms array of validation types into fully qualified class names
     * @param array $requiredValidators
     * @return array
     */
    private function getQualifiedNames(array $requiredValidators)
    {
        return array_map(function($typeName){
            return $this->provider->getModelClassName($typeName);
        }, $requiredValidators);
    }

}

when i call job->updateStatus a lot of things happen and many events could be triggered, some of which need to know who is logged in.

Ok. My two cents is you should try to abstract the user when using events/jobs by passing the user to them when firing them.

$job->updateStatus($user, true);

It is just an advice you do whatever you want :)