[PROMOÇÃO] Assine com + 30% de desconto ANUAL MENSAL (últimas horas)
Matthaus nawan
Criador Matthaus nawan 20/11/2018

Argument 1 passed to Illuminate\Auth\SessionGuard::login() must implement interface Illuminate\Contracts\Auth\Authenticatable, null given, called in C:\laragon\www\flintstones\vendor\laravel\framework\src\Illuminate\Foundation\Auth\RegistersUsers.php on line 35

 

 

usando laravel 5.7

consigo registrar o tenant e o usuario mas esse erro é reportado

Manager Carlos Ferreira 20/11/2018

Olá, Matthaus!
Como vai?

Me mostra como ficou o seu código, preciso de mais detalhes para identificar onde você errou.

Carlos Ferreira
Criador Matthaus nawan 20/11/2018

Opa Professor, eu acabei descobrindo o erro. estava faltando o return no metodo create em RegisterController... Mesmo assim obrigado! eu deixei uma publicação no facebook sobre uma duvida que surgio. Por exemplo: É possivel usar a estrutura de autenticação desse curso para criar usuarios(clientes) de cada tenant?

Cenário: Cada tenant(consultor) teria seus clientes(usuarios), levando em consideração que o atributo 'tenant_id" é obrigatorio na tabela users :| . Seria mais facil criar outra tabela, e outro sistema de autenticação somente para esse caso específico? Ou estou querendo matar uma formiga com uma bazooca?

Matthaus nawan
Manager Carlos Ferreira 20/11/2018

Olá, Matthaus!

Que bom que conseguiu identificar o erro, parabéns! :)

Entendi o seu caso, existem N linhas de desenvolvimento que você pode seguir.

No caso desse projeto do curso, trabalhamos com o usuário relacionado diretamente com o tenant, ou seja, um usuário está obrigatoriamente ligado a um tenant_id.
Caso queira seguir essa linha, e manter todos os usuários (admins) na tabela users, e também manter os clientes daquele tenant na tabela users, também pode. Nesse modelo todos compartilham o mesmo tenant_id, tanto os admins quantos os tentans.

Ah, mas como diferenciar no tenant X quem é admin e pode ter privilégios, e quem é um cliente dele?
Existem algumas alternativas para esse caso, você pode ter uma coluna adicional na tabela users que indica o tipo do usuário (pode ser um coluna ENUM), ou melhor ainda, você pode trabalhar com ACL (níveis de acesso) e definir perfis/roles para cada usuário do tenant, porque dessa forma você amarra o usuário diretamente com o perfil/roles e suas permissões.

Entendeu a ideia? Era essa mesmo a sua dúvida?

PS. Dá uma olhada no curso de multi-tenancy single database (subdomain), ele pode se encaixar melhor ao que você precisa.

Carlos Ferreira
Sabe a Solução? Ajude a resolver!

Precisa estar logado para conseguir responder a este ticket!

Clique Aqui Para Entrar!