JhaoDa

Не авторизацию, а аутентификацию. В документации написано, как.

А зачем вы туда передаёте хэш пароля вместо самого пароля? Если у вас свой механизм хэширования паролей, так и напишите для него обвязку, либо не используйте Auth::attempt, потому что у него внутри (вот удивительно!) хэшируются пароли при сравнении.

P.S. И да, в данном контексте не «авторизация», а «аутентификация».

Ловите события https://laravel.com/docs/5.6/queues#job-events и проверяйте, что за задача выполняется/выполнена/упала/етц.

Читать документацию пробовали?
Например, https://laravel.com/docs/5.6/middleware но это всё равно костыль, потому что единственно верное решение — переписать контроллер.
Вы если что, то только намекните — я в полицию позвоню, потому что вам, похоже, угрожают и запрещают менять контроллер. Иных причин не вижу.

https://laravel.com/docs/5.6/pagination#displaying...

Laravel глубоко пофигу, это уже бизнес-логика. Проблема может быть только в обратную сторону, если к контракту привязывать юзера:

// что за юзер — провайдер или потребитель?
// по какому полю строить связь?
$contract->user()->associate($user);

Впрочем, судя по всему, достаточно на другой стороне подобную конструкцию с условиями сделать. Но могут быть проблемы: создали инстанс модели, provider_id и customer_id не заполнили — что в условиях проверять?