Se você chegou aqui pesquisando o erro "Public Key Retrieval is not allowed" ao tentar conectar no MySQL pelo DBeaver, pode pular direto para essa seção. Se está começando do zero, siga o tutorial completo abaixo.

Neste guia você vai aprender a:

• Subir um container MySQL com Docker Compose, com dados persistidos na sua máquina

• Evitar os dois erros mais comuns dessa configuração

• Conectar no banco usando o DBeaver

Pré-requisitos

• Docker instalado (docker --version para conferir)

• Docker Compose instalado, de preferência a versão mais recente, integrada como plugin (docker compose version, sem hífen)

• DBeaver instalado (ou qualquer outro cliente MySQL de sua preferência)

Passo 1: criando o docker-compose.yml

Crie uma pasta para o projeto e, dentro dela, um arquivo docker-compose.yml:

services:
  mysql_knex:
    container_name: mysql_knex
    hostname: mysql_knex
    image: mysql:8.0
    restart: always
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
      - --innodb_force_recovery=0
    volumes:
      - ~/.MySQLDBData/mysqlonly/mysql_knex:/var/lib/mysql
    ports:
      - 3306:3306
    environment:
      MYSQL_ROOT_PASSWORD: senha
      MYSQL_DATABASE: base_de_dados
      MYSQL_USER: usuario
      MYSQL_PASSWORD: senha
      TZ: America/Sao_Paulo

Alguns pontos importantes desse arquivo:

Fixe a versão da imagem. Usar image: mysql sem tag puxa sempre a versão mais recente disponível no Docker Hub. Isso é perigoso: uma versão nova pode remover flags que seu comando usa, quebrando a inicialização do container. Fixando mysql:8.0, você garante um comportamento previsível.

O volume persiste os dados no seu host. A linha abaixo é o que garante que, se você derrubar o container, os dados não somem:

volumes:
  - ~/.MySQLDBData/mysqlonly/mysql_knex:/var/lib/mysql

Você pode confirmar seu caminho com echo $HOME. Se quiser evitar qualquer ambiguidade (por exemplo, ao rodar com sudo, onde ~ viraria /root), use o caminho absoluto direto no lugar do ~.

Passo 2: subindo o container

Na pasta onde está o docker-compose.yml, rode:

docker compose up -d

Confirme que subiu com:

docker ps

O container mysql_knex deve aparecer com status Up. Se aparecer Restarting, o processo está travando em loop — siga para a próxima seção.

Erro: unknown variable 'default-authentication-plugin'

Se você usou algum tutorial mais antigo como referência, é comum ver a flag --default-authentication-plugin=mysql_native_password no command: do compose. Em versões recentes do MySQL, essa flag não existe mais, e o servidor recusa iniciar, entrando em crash loop.

Para confirmar que é esse o problema, veja os logs:

docker logs mysql_knex --tail 50

Se aparecer algo como:

[ERROR] [MY-000067] [Server] unknown variable 'default-authentication-plugin=mysql_native_password'.
[ERROR] [MY-010119] [Server] Aborting

A solução é remover essa flag do command: (como já está no docker-compose.yml deste tutorial) e deixar o MySQL 8 usar seu método de autenticação padrão, o caching_sha2_password.

Se o container já tentou subir e crashou antes de terminar a inicialização, é seguro resetar o volume, já que nenhum dado real chegou a ser gravado:

docker compose down
sudo rm -rf ~/.MySQLDBData/mysqlonly/mysql_knex
docker compose up -d

Depois disso, confira os logs de novo e espere aparecer a linha:

[Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.43' ...

Isso confirma que o MySQL subiu corretamente e está pronto para aceitar conexões.

Passo 3: conectando pelo DBeaver

Abra o DBeaver e crie uma nova conexão MySQL, com os dados do seu docker-compose.yml:

• Host: localhost

• Port: 3306

• Database: o valor de MYSQL_DATABASE

• Username: o valor de MYSQL_USER

• Password: o valor de MYSQL_PASSWORD

Erro: Public Key Retrieval is not allowed

Ao testar a conexão, é bem provável que apareça este erro:

Public Key Retrieval is not allowed

Isso acontece porque o MySQL 8 usa o plugin de autenticação caching_sha2_password, que exige buscar uma chave pública RSA do servidor para autenticar com segurança. Por padrão, o driver JDBC bloqueia essa busca automática — é uma proteção contra ataques man-in-the-middle. Em ambiente de desenvolvimento local, é seguro habilitar manualmente.

Como resolver no DBeaver:

1. Abra a conexão em Edit Connection.

2. Vá até a aba Driver properties.

3. Localize a propriedade allowPublicKeyRetrieval e defina como true. Se não existir na lista, adicione manualmente clicando no ícone +.

   

4. Confirme também que useSSL está como false, já que não há certificado SSL configurado para produção nesse ambiente local.

   

5. Clique em OK e teste a conexão novamente.

Alternativa mais rápida: editar direto a URL JDBC, na aba Main:

jdbc:mysql://localhost:3306/base_de_dados?allowPublicKeyRetrieval=true&useSSL=false

TCP/IP vs Unix socket: por que a porta importa

Um detalhe que gera confusão: nos logs do MySQL você vai ver uma linha assim:

ready for connections. ... socket: '/var/run/mysqld/mysqld.sock' port: 3306

O MySQL aceita conexões de duas formas:

• TCP/IP, via localhost:3306 — é o que o DBeaver usa, mesmo estando na mesma máquina, porque ele roda fora do container e precisa atravessar a rede até o processo do MySQL.

• Unix socket, via o arquivo mysqld.sock — só acessível por processos dentro do mesmo container, como quando você entra nele diretamente com docker exec -it mysql_knex mysql -u root -p.

Por isso, garantir que a porta 3306:3306 esteja mapeada corretamente no docker-compose.yml é essencial para qualquer cliente externo, como o DBeaver, conseguir se conectar.

Bônus: comandos úteis para o dia a dia

Parar o container sem apagar dados:

docker stop container_name

Voltar a subir depois de parado:

docker start container_name

Ver logs em tempo real:

docker logs -f mysql_knex

Fazer backup do banco (dump):

docker exec mysql_knex mysqldump -u root -p base_de_dados > backup.sql

Restaurar um backup:

docker exec -i mysql_knex mysql -u root -p base_de_dados < backup.sql

Resetar tudo do zero (⚠️ apaga os dados permanentemente):

docker compose down
sudo rm -rf ~/.MySQLDBData/mysqlonly/mysql_knex
docker compose up -d

Conclusão

Com esse setup você tem um MySQL rodando em container, com dados persistidos fora dele (então derrubar o container não te faz perder nada), e uma conexão funcional via DBeaver para gerenciar o banco visualmente. Os dois erros cobertos aqui — a flag de autenticação obsoleta e a recuperação de chave pública — são praticamente um rito de passagem para quem sobe MySQL 8 em Docker pela primeira vez, então se você travou neles, está em boa companhia.

Ngrok permite expor um serviço local (por exemplo, um servidor web rodando no seu PC) para a internet por meio de um túnel seguro, sem precisar configurar redirecionamento de portas no roteador ou DNS complicada.

Requisitos prévios

Antes de começar, você precisa:

• Ter uma conta no ngrok (gratuita ou paga).

• Ter acesso ao terminal no Linux (shell).

• Saber qual serviço/porta local você quer expor (por exemplo, servidor web em localhost:3000).

Faça o login com uma conta do github ou google. Em seguida, siga esses passos!

Instale o ngrok via Apt com o seguinte comando:

curl -sSL https://ngrok-agent.s3.amazonaws.com/ngrok.asc \
  | sudo tee /etc/apt/trusted.gpg.d/ngrok.asc >/dev/null \
  && echo "deb https://ngrok-agent.s3.amazonaws.com bookworm main" \
  | sudo tee /etc/apt/sources.list.d/ngrok.list \
  && sudo apt update \
  && sudo apt install ngrok

Execute o seguinte comando para adicionar seu authtoken ao arquivo de configuração padrão ngrok.yml.

ngrok config add-authtoken seu_token

No arquivo será adicionado o seu token.

Agora veja a aplicação rodando no localhost sem o protocolo de segurança, muita das vezes utilizamos alguns serviços que exigem https.

Agora é que vem a mágica.

Faça o deploy do seu aplicativo, execute o seguinte na linha de comando:

ngrok http 8074

Acesse seu domínio de desenvolvimento para ver seu aplicativo!

https://unforsaken-extrusile-ainsley.ngrok-free.dev

Vai aparecer essa tela mas não se preocupe, clique no botão azul.

Nossa aplicação está carregando, porém precisamos corrigir as urls para que o css e o javascript carreguem. Como a aplicação é um site em wordpress, basta inserir essas linhas no arquivo wp-config.php

define('WP_HOME','https://unforsaken-extrusile-ainsley.ngrok-free.dev');
define('WP_SITEURL','https://unforsaken-extrusile-ainsley.ngrok-free.dev');

Agora nossa aplicação carregou perfeitamente.

Em nosso terminal, podemos visualizar o status de todas as requisições no HTTP Requests.

O ngrok cria uma interface de inspeção web local, onde você consegue ver todas as requisições que passam pelo túnel.

🔗 A URL padrão é:

http://127.0.0.1:4040

O que você encontra lá:

• Lista de todas as requisições que chegaram ao túnel.

• Método HTTP (GET, POST, PUT etc.).

• Status de resposta (200, 404, 500…).

• Corpo da requisição e da resposta.

• Possibilidade de repetir requisições para testar seu servidor local.

👉 Dica: se você precisar acessar essa interface de outro dispositivo ou servidor, dá para expor também o painel (ngrok http 4040), mas normalmente ele só fica disponível localmente por segurança.

📌 Resumo

O ngrok é uma ferramenta poderosa para desenvolvedores que precisam expor serviços locais na internet de forma rápida e segura. Com ele, é possível compartilhar aplicações em desenvolvimento, realizar testes de integrações externas, validar webhooks e até mesmo acessar serviços internos sem configuração de rede complexa.

📚 Referências

• Documentação oficial do ngrok — Setup Linux

• ngrok Docs — Getting Started

• ngrok Docs — Tunnels Configuration

• ngrok Docs — API & Inspector

Neste tutorial vamos:

1. Criar uma instância no Play with Docker

2. Conectar via SSH no nosso terminal local

3. Validar o acesso e começar os testes

https://labs.play-with-docker.com/

1. Criando uma instância no Play with Docker

1. Acesse Play with Docker.

2. Clique em Login (você pode usar sua conta do Docker Hub).

3. Na tela inicial, clique em + ADD NEW INSTANCE.

Você verá algo assim:

Cada instância criada terá:

• Um IP interno (ex: 192.168.0.14)

• Um comando SSH já pronto para conectar

2. Conectando via SSH

No painel da instância, você verá o comando SSH parecido com este:

ssh ip172-18-0-5-d38rg40l2o9000840akg@direct.labs.play-with-docker.com

Copie esse comando e cole no seu terminal local (Linux ou WSL).
Na primeira conexão, será exibido um aviso de autenticidade:

The authenticity of host 'direct.labs.play-with-docker.com (...)' can't be established.
RSA key fingerprint is ...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Digite yes e pressione Enter.

3. Verificando a conexão

Após conectar, você terá acesso a um ambiente Linux remoto. A linha do terminal deve mudar para algo como:

[node1] (local) root@192.168.0.14 ~ $

Pronto! Agora você pode começar a rodar comandos básicos de Linux, como:

ls
pwd
whoami

🚀 Conclusão

Com o Play with Docker, você tem um laboratório Linux rápido e prático para treinar os fundamentos sem precisar configurar máquinas virtuais.

👉 Dica: você pode salvar esse tutorial como referência para seus estudos ou até compartilhar com colegas que também estão começando no Linux.

✅ O que é o Flameshot?

O Flameshot é uma ferramenta de captura de tela com editor embutido, que permite destacar, desenhar, adicionar setas, texto e muito mais. Perfeita para quem quer ir além do simples “Print Screen”.

📦 Instalando o Flameshot no Pop!_OS

Pop!_OS é baseado no Ubuntu, então a instalação é bem tranquila via terminal:

1. Abra o terminal

2. Digite o comando abaixo para atualizar os repositórios:

    sudo apt update
   

3. Agora instale o Flameshot:

    sudo apt install flameshot
   

4. Verifique se foi instalado corretamente:

    flameshot --version
   

🔥 Usando o Flameshot

Para fazer uma captura de tela a qualquer momento:

flameshot gui

Isso abrirá a interface interativa de captura. A partir daí, é só selecionar a área desejada e usar as ferramentas visuais.

🎯 Criando um Atalho de Teclado Personalizado

Quer usar o Flameshot com a tecla Print Screen? Veja como:

1. Vá até Settings (Configurações) no Pop!_OS

2. Clique em Keyboard no menu lateral

3. Desça até o final e clique em “View and Customize Shortcuts”

   

4. Role até Custom Shortcuts e clique no botão “+” (Add Shortcut)

   

   

5. Preencha os campos:

   

   • Name: Flameshot

   • Command: flameshot gui

   • Shortcut: clique em “Set Shortcut” e pressione a tecla Print Screen

Se a tecla Print Screen já estiver em uso por outro atalho, você pode removê-lo ou usar uma combinação como Ctrl + Shift + P.

🚀 Pronto para capturar!

Com o Flameshot instalado e um atalho configurado, suas capturas de tela no Pop!_OS ficam muito mais rápidas e organizadas. Ideal para tutoriais, documentação ou qualquer tarefa que envolva imagens da tela com anotações.

flameshot
documentação

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Não se preocupe! Esse erro ocorre porque o GitHub não conseguiu autenticar sua chave SSH. Neste guia, vamos mostrar um passo a passo para solucionar esse problema e garantir que você consiga acessar seus repositórios sem dificuldades.

O Que Causa Esse Erro?

O erro "Permission denied (publickey)" normalmente acontece por um dos seguintes motivos:

1. Você não tem uma chave SSH configurada no seu computador.

2. Sua chave SSH não está adicionada ao GitHub.

3. O agente SSH não está em execução ou sua chave não está carregada.

4. Você está tentando clonar usando SSH, mas sua conta só permite acessos via HTTPS.

Agora, vamos resolver o problema!

Passo 1: Verificar Se Você Tem Uma Chave SSH Configurada

Primeiro, verifique se já existe uma chave SSH no seu sistema. Abra o terminal e digite:

ls -al ~/.ssh

Se o comando listar arquivos como id_rsa e id_rsa.pub ou id_ed25519 e id_ed25519.pub, significa que você já tem uma chave SSH configurada.

Se não houver chaves, você precisa gerar uma nova.

Passo 2: Criar Uma Nova Chave SSH (Se Necessário)

Se você precisa criar uma nova chave SSH, utilize este comando:

ssh-keygen -t ed25519 -C "seu-email@example.com"

Caso seu sistema não suporte Ed25519, use RSA:

ssh-keygen -t rsa -b 4096 -C "seu-email@example.com"

Depois de rodar esse comando, pressione Enter para confirmar o local padrão da chave e, se quiser, defina uma senha.

Passo 3: Adicionar a Chave SSH ao GitHub

Agora, você precisa adicionar sua chave SSH ao GitHub:

1. Pegue a chave pública com este comando:

    cat ~/.ssh/id_ed25519.pub  # Ou ~/.ssh/id_rsa.pub se for RSA
   

2. Copie o conteúdo exibido.

3. Acesse GitHub → Configurações → SSH and GPG keys.

4. Clique em New SSH Key.

5. Cole a chave pública e salve.

Passo 4: Testar a Conexão SSH com o GitHub

Para verificar se a autenticação SSH está funcionando, rode:

ssh -T git@github.com

Se tudo estiver correto, você verá uma mensagem como esta:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Passo 5: Certificar-se de que o Agente SSH Está Rodando

Se o erro persistir, pode ser que sua chave SSH não esteja carregada. Para resolver isso, execute:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519  # Ou ~/.ssh/id_rsa

Passo 6: Alternativa - Usar HTTPS ao Invés de SSH

Se você não quiser usar SSH, pode clonar o repositório via HTTPS:

git clone https://github.com/usuario/repositorio.git

Isso não exige chaves SSH, mas você precisará inserir suas credenciais toda vez que fizer push ou pull.

Conclusão

Seguindo esses passos, você deve conseguir corrigir o erro "Permission denied (publickey)" e acessar seus repositórios no GitHub sem problemas. Se o erro persistir, verifique se a chave correta está sendo usada e se sua conta GitHub está configurada corretamente.

Agora é só codar e versionar seus projetos sem dores de cabeça! 🚀

• Ambiente com suporte a Node.js e npm (como o StackBlitz ou sua máquina local)

• Um editor de código (VS Code, StackBlitz, etc.)

1. Inicializar projeto

Se estiver começando do zero (localmente):

mkdir meu-projeto-tailwind
cd meu-projeto-tailwind
npm init -y

Isso cria o package.json e estrutura mínima.

/meu-projeto-tailwind
│
├── index.html
├── tailwind.css
├── styles.css
├── tailwind.config.js
└── package.json (criado automaticamente ao instalar Tailwind)

(No StackBlitz talvez já haja um ambiente inicial, então você pode pular esse passo se já existir package.json.)

Passo 2: Instalar Tailwind CSS e dependências

Execute:

npm install -D tailwindcss@3.4.17 postcss autoprefixer
npx tailwindcss init -p

Explicações:

• tailwindcss@3.4.17 força instalar essa versão (ou algo próximo)

• postcss e autoprefixer são usados para processar CSS e adicionar prefixos necessários

• npx tailwindcss init -p cria dois arquivos:

  • tailwind.config.js

  • postcss.config.js

Após isso, você terá:

/meu-projeto-tailwind
│
├── node_modules/
├── index.html
├── tailwind.css
├── styles.css
├── postcss.config.js
├── tailwind.config.js
└── package.json (criado automaticamente ao instalar Tailwind)

No tailwind.config.js, o conteúdo padrão será algo como:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [],
  theme: {
    extend: {},
  },
  plugins: [],
}

No postcss.config.js, geralmente:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}

Passo 3: Configurar os caminhos de “content” (template paths)

O Tailwind precisa saber onde procurar suas classes (em arquivos HTML, JS, etc) para gerar CSS apenas para as classes usadas. Isso ajuda a tree-shake (remover classes não utilizadas) e reduzir o tamanho final do CSS.

No seu tailwind.config.js, edite a propriedade content. Por exemplo, para um projeto simples:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./*.html",
    "./src/**/*.{html,js}",  // se você tiver pasta `src`
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Se seus arquivos HTML, JS, componentes estiverem em outras pastas, inclua seus padrões.

Esse passo é fundamental para que o Tailwind “veja” as classes que você usa e inclua os estilos gerados.

Passo 4: Criar arquivo CSS de entrada (input CSS)

Crie um arquivo CSS (por exemplo src/tailwind.css ou src/css/tailwind.css) com o seguinte conteúdo:

@tailwind base;
@tailwind components;
@tailwind utilities;

/* Aqui você pode adicionar suas próprias regras CSS ou usar @layer / @apply */

Esse arquivo será o ponto de entrada do Tailwind para gerar o CSS final.

Passo 5: Compilar o CSS

Agora você deve “processar” o tailwind.css junto com as configurações para gerar um CSS final (ex: dist/output.css). Há várias formas de fazer isso:

Usando Tailwind CLI

Esse é o método mais simples:

npx tailwindcss -i ./src/tailwind.css -o ./dist/output.css --watch

Explicação:

• -i: arquivo de entrada (input)

• -o: arquivo de saída (output)

• --watch: fica observando alterações e recompila automaticamente

Depois disso, o arquivo dist/output.css será gerado e atualizado conforme você altera seus arquivos HTML ou CSS.

Esse método é também o indicado na documentação oficial.

Usando PostCSS / bundlers (webpack, Vite, etc)

Se você tiver um pipeline mais avançado:

• Seu bundler (webpack, Vite, Rollup...) já executa PostCSS como parte da cadeia de build.

• No postcss.config.js, você já incluiu tailwindcss e autoprefixer.

• Você importa ou referencia no build esse input.css (ou outro arquivo) para ser processado.

Por exemplo, no Vite, você coloca:

// vite.config.js (exemplo)
import { defineConfig } from "vite"

export default defineConfig({
  css: {
    postcss: true
  }
})

E no seu código (por exemplo main.js):

import "./tailwind.css"

E o bundler cuidará de compilar com PostCSS e gerar CSS final.

A documentação do Tailwind tem guias específicos para frameworks, como Vite.

Passo 6: Incluir CSS compilado no HTML

No seu arquivo HTML (ex: index.html), no <head>, incluia:

<link rel="stylesheet" href="./dist/output.css">

Ou o caminho correto para seu CSS de saída.

Exemplo mínimo:

<!DOCTYPE html>
<html lang="pt-br">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <link href="dist/output.css" rel="stylesheet" />
  <title>Projeto Tailwind</title>
</head>
<body>
  <h1 class="text-3xl font-bold underline">Olá, Tailwind!</h1>
</body>
</html>

Se o CSS compilado estiver sendo servido por outra rota ou servidor, ajuste a URL de acordo.

Passo 7: Usar classes utilitárias no HTML

Agora é a parte divertida: você já pode usar as classes do Tailwind no seu HTML.

Alguns exemplos:

<button class="px-4 py-2 bg-blue-600 text-white rounded hover:bg-blue-700">
  Clicar
</button>

<div class="max-w-md mx-auto mt-10">
  <p class="text-gray-700 leading-relaxed">
    Exemplo com Tailwind CSS.
  </p>
</div>

Você pode combinar classes utilitárias para layout, cores, espaçamento, tipografia, responsividade etc.

Passo 8: Customizações e refinamentos (opcional)

Depois que tudo estiver funcionando, você pode:

• Estender tema no tailwind.config.js (cores, fontes, espaçamentos, etc)

• Usar @apply para criar classes personalizadas

• Usar @layer components ou @layer utilities

• Instalar plugins do Tailwind (por exemplo tipografia, forms)

• Ativar modo “dark”, variantes e outras configurações

• Certificar-se de que o “purge” / remoção de CSS não usado esteja funcionando bem (configuração content)

Tailwind CSS é um framework utilitário para criação rápida de interfaces com classes pré-definidas. A versão 3.4.17 inclui recursos modernos como JIT (Just-In-Time), dark mode, variantes estendidas, e mais.

📚 Referências

• 📘 Documentação oficial do Tailwind CSS v3

• 📘 Guia de instalação via CLI

• 📘 Conteúdo sobre paths no Tailwind

• 📘 Tailwind CSS no StackBlitz (exemplo usado pelo usuário)

O Zsh é projetado para ser compatível com o Bash, mas oferece funcionalidades adicionais, como autocompletar avançado, sugestões de comandos, e uma personalização extensiva por meio de temas e plugins.

Principais Características do Zsh

1. Autocompletar Inteligente: O Zsh possui um autocompletar avançado que sugere opções e argumentos de comandos, facilitando a execução rápida e precisa de comandos.

2. Correção de Erros de Digitação: Ele pode corrigir automaticamente comandos digitados incorretamente ou sugerir correções para os erros, tornando a experiência de uso mais agradável.

3. Histórico de Comandos Aprimorado: O histórico de comandos do Zsh é mais robusto, com recursos de pesquisa interativa e reutilização de comandos anteriores.

4. Suporte a Plugins e Temas: Com frameworks como Oh My Zsh, o Zsh oferece suporte fácil para plugins e temas, que podem melhorar a funcionalidade e a aparência do terminal.

5. Globbing Avançado: O Zsh permite correspondência avançada de padrões de nomes de arquivos, o que é útil para buscar e manipular arquivos de forma mais complexa.

6. Aliases e Funções Personalizadas: O Zsh facilita a criação de aliases (atalhos para comandos) e funções personalizadas, melhorando a produtividade e a eficiência.

Para que Serve o Zsh?

O Zsh é usado principalmente para melhorar a experiência de uso do terminal. Ele oferece recursos que facilitam a execução de tarefas repetitivas, o uso de atalhos, e a personalização do ambiente de trabalho. Por isso, é uma escolha popular entre desenvolvedores, administradores de sistemas e entusiastas do Linux que desejam um terminal mais eficiente e produtivo.

Passo a Passo para Instalação do Zsh no Pop!_OS

1. Atualizar o sistema

   Antes de instalar o Zsh, é recomendado atualizar o sistema para garantir que todos os pacotes estejam nas versões mais recentes:

    sudo apt update && sudo apt upgrade -y
   

2. Instalar o Zsh

   Para instalar o Zsh, use o comando abaixo:

    sudo apt install zsh -y
   

   Isso instalará o Zsh a partir dos repositórios padrão do Pop!_OS.

3. Verificar a instalação

   Para garantir que o Zsh foi instalado corretamente, execute o comando:

    zsh --version
   

   Você verá a versão do Zsh instalada, o que indica que a instalação foi bem-sucedida.

4. Configurar o Zsh como o shell padrão

   Para definir o Zsh como o shell padrão do usuário, use o comando:

    chsh -s $(which zsh)
   

   Isso configurará o Zsh como o shell principal. É necessário fazer logout e login novamente para que a mudança tenha efeito.

5. Instalar o Oh My Zsh (opcional, mas recomendado)

   Oh My Zsh é um framework de código aberto para gerenciar a configuração do Zsh. Ele facilita a personalização com temas e plugins. Para instalar o Oh My Zsh, execute:

    sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
   

   Isso instalará o Oh My Zsh e criará automaticamente um arquivo de configuração .zshrc no diretório home.

6. Personalizar o Zsh

    ZSH_THEME="robbyrussell"
   

   Você pode substituir "robbyrussell" pelo nome de outro tema disponível.

7. Adicionar Plugins
   O Zsh suporta plugins que melhoram a funcionalidade do terminal. Por exemplo, para ativar o plugin git, edite o arquivo ~/.zshrc e adicione git à lista de plugins:

    plugins=(git)
   

   Após modificar o arquivo, atualize o Zsh com o comando:

    source ~/.zshrc
   

Themes to ohmyzsh

External themes to ohmyszh

Spaceship Prompt

Conclusão

O Zsh é uma excelente opção para quem busca um shell mais avançado e customizável. Com suas funcionalidades aprimoradas, ele pode tornar o uso do terminal mais eficiente e produtivo. Além disso, a instalação e configuração são simples, especialmente com o uso de frameworks como o Oh My Zsh.

Por que dominar os tipos de teste?

Dominar os tipos de teste é o primeiro passo para garantir entregas com qualidade.
Cada tipo tem um objetivo, uma fase ideal de aplicação e um impacto direto na qualidade do produto.

Quando o QA compreende o que precisa ser validado e como, ele consegue detectar falhas mais cedo, reduzir custos de correção e contribuir para um produto mais estável e confiável.

🔍 1. Teste Unitário

Objetivo: Validar o funcionamento isolado de partes pequenas do código (funções, métodos, classes).
Responsável: Normalmente o desenvolvedor.
Ferramentas: Jest, JUnit, NUnit, PyTest.

💡 É o primeiro nível de verificação. Ajuda a detectar erros logo no início do desenvolvimento.

🧩 2. Teste de Integração

Objetivo: Garantir que diferentes módulos do sistema funcionem corretamente em conjunto.
Responsável: QA ou desenvolvedor.
Ferramentas: Postman, Newman, Supertest.

💬 Exemplo: testar se o módulo de login comunica-se corretamente com o banco de dados e o sistema de autenticação.

🌐 3. Teste de Sistema

Objetivo: Validar o sistema como um todo, garantindo que todas as funcionalidades atendam aos requisitos.
Responsável: QA.
Ferramentas: Selenium, Cypress, Playwright.

🧭 É aqui que se verifica a aplicação de ponta a ponta, simulando o comportamento real do usuário.

👥 4. Teste de Aceitação

Objetivo: Confirmar se o sistema atende às expectativas e requisitos do cliente.
Responsável: QA e cliente.
Ferramentas: Cucumber, Behave.

✅ Normalmente é a última fase antes da entrega do produto.

⚙️ 5. Teste de Regressão

Objetivo: Garantir que novas alterações no código não afetaram funcionalidades já existentes.
Responsável: QA (com foco em automação).
Ferramentas: Cypress, Selenium, Jenkins (CI/CD).

🔁 É essencial após correções de bugs e novas implementações.

🚀 6. Teste de Performance

Objetivo: Avaliar o desempenho, escalabilidade e estabilidade da aplicação sob diferentes cargas de uso.
Responsável: QA especializado.
Ferramentas: JMeter, Gatling, k6.

📊 Mede tempo de resposta, uso de recursos e comportamento em cenários de estresse.

🔒 7. Teste de Segurança

Objetivo: Identificar vulnerabilidades e falhas que possam ser exploradas por ataques.
Responsável: QA de segurança ou equipe especializada.
Ferramentas: OWASP ZAP, Burp Suite.

🛡️ Protege os dados dos usuários e garante a conformidade com normas de segurança.

📱 8. Teste de Usabilidade

Objetivo: Avaliar a experiência do usuário (UX) — clareza, acessibilidade e facilidade de uso.
Responsável: QA em conjunto com equipe de UX/UI.
Ferramentas: Hotjar, Maze, testes A/B.

👀 O foco é o usuário final — quanto mais simples e intuitiva a aplicação, melhor.

💡 Conclusão

Ser QA é muito mais do que testar funcionalidades. É garantir qualidade desde o início do processo de desenvolvimento.

Dominar os tipos de teste permite uma visão ampla sobre o produto, antecipando riscos e entregando valor real ao usuário.

“Qualidade não se adiciona no final, ela é construída em cada etapa do desenvolvimento.”

Conventional Commits é uma convenção para escrever mensagens de commit de forma estruturada e padronizada. Ele define um formato claro para facilitar a leitura, automação de processos e compreensão do histórico de mudanças em um projeto.

Essa convenção é especialmente útil em projetos com múltiplos colaboradores, pois melhora:

• A comunicação entre os membros da equipe;

• A geração automatizada de changelogs;

• A identificação de versões semânticas (SemVer);

• A integração com ferramentas de CI/CD (como GitHub Actions e Semantic Release).

A ideia central é prefixar as mensagens com tipos de alterações (como feat, fix, docs, etc.), seguidos de uma breve descrição.

Por exemplo:

feat: adicionar página de login

Iniciando o uso

Para adotar a convenção Conventional Commits no seu projeto, siga estes passos:

1. Familiarize-se com a estrutura padrão:

    <tipo>[!][(escopo)]: <descrição curta>
   

   Onde:

   • tipo: tipo da mudança (feat, fix, docs, etc.).

   • escopo (opcional): onde a mudança ocorreu (ex: login, api, header).

   • !: indica uma mudança que quebra compatibilidade (breaking change).

   • descrição curta: explicação clara e objetiva da mudança.

2. Tipos mais comuns:

   • feat: uma nova funcionalidade

   • fix: correção de bug

   • docs: mudanças na documentação

   • style: ajustes de formatação (espaços, ponto e vírgula, etc.)

   • refactor: refatorações sem alterar comportamento

   • test: adição ou ajuste de testes

   • chore: tarefas que não afetam o código de produção (ex: scripts, configs)

3. Ferramentas úteis:

   • commitlint: valida mensagens de commit.

   • husky: aplica hooks no Git para rodar o commitlint automaticamente.

   • semantic-release: gera changelogs e publica versões automaticamente com base nos commits.

Exemplos práticos

Aqui estão alguns exemplos de mensagens de commit seguindo a convenção:

feat(auth): adicionar autenticação via Google
fix(api): corrigir erro 500 ao buscar usuários inativos
docs(readme): atualizar instruções de instalação
style(header): remover espaço extra no CSS
refactor(user-service): otimizar função de login
test(profile): adicionar testes para edição de perfil
chore(ci): configurar pipeline do GitHub Actions

Breaking changes:

feat!: remover suporte à versão antiga da API

Ou, em uma mensagem de commit multi-linha:

refactor(core): remover função obsoleta de validação

BREAKING CHANGE: a função validateOldInput foi removida e substituída por validateInput.

Conclusão

Adotar a convenção Conventional Commits é um pequeno passo que traz grandes benefícios para o desenvolvimento de software. A padronização das mensagens melhora a colaboração, facilita automações e garante um histórico mais compreensível e útil.

Seja em projetos pessoais ou em grandes equipes, aplicar essa convenção contribui diretamente para a manutenibilidade, escalabilidade e profissionalismo do código.

O que é Docker?

Docker é uma plataforma de código aberto que automatiza a implantação de aplicativos dentro de contêineres de software. Esses contêineres permitem que um aplicativo seja empacotado com todas as suas dependências e bibliotecas necessárias, garantindo que ele funcione de maneira consistente em qualquer ambiente onde Docker esteja sendo executado.

Benefícios de Utilizar Docker

1. Portabilidade e Consistência: Com Docker, você pode empacotar seu aplicativo e suas dependências em um contêiner, garantindo que ele se comporte da mesma maneira, independentemente do ambiente de desenvolvimento, teste ou produção.

2. Eficiência de Recursos: Contêineres Docker compartilham o núcleo do sistema operacional host, o que os torna mais leves em comparação com máquinas virtuais tradicionais, resultando em maior eficiência de recursos e custos reduzidos.

3. Escalabilidade: Docker facilita a escalabilidade horizontal e vertical, permitindo que você dimensione seus aplicativos de acordo com a demanda, de forma rápida e eficiente.

4. Facilidade de Gerenciamento: Com Docker, é possível automatizar tarefas de implantação, atualização e manutenção de aplicativos, reduzindo significativamente a carga operacional sobre equipes de TI.

Como Começar com Docker

Para começar a aproveitar os benefícios do Docker, siga estes passos básicos:

1. Instalação: Baixe e instale o Docker Engine em seu sistema operacional. Docker oferece suporte para Windows, macOS e Linux, facilitando a integração em diversos ambientes de desenvolvimento.

   💡

   https://docs.docker.com/desktop/install/linux-install/

   Por exemplo, no Linux, você pode usar o comando:

    sudo apt-get install docker-ce
   

2. Criação de Imagens: Utilize Dockerfiles para definir o ambiente e as dependências do seu aplicativo. Isso permite que você crie imagens Docker personalizadas que podem ser compartilhadas e reutilizadas por toda a equipe de desenvolvimento.

   Crie um Dockerfile para um aplicativo Node.js. Por exemplo:

    FROM node:14
    WORKDIR /app
    COPY package.json .
    RUN npm install
    COPY . .
    CMD ["npm", "start"]
   

3. Execução de Contêineres: Uma vez que sua imagem Docker esteja pronta, você pode executá-la como um contêiner. Isso cria uma instância isolada do seu aplicativo que pode ser escalada horizontalmente conforme necessário.

   Execute o contêiner do Node.js com:

    docker build -t meu-app .
    docker run -p 3000:3000 meu-app
   

4. Implantação em Produção: Para ambientes de produção, utilize orquestradores como Kubernetes ou Docker Swarm para gerenciar múltiplos contêineres Docker e automatizar tarefas de implantação e monitoramento.

   Use Docker Compose para orquestrar múltiplos contêineres. Por exemplo, um arquivo docker-compose.yml para um aplicativo com front-end React e back-end Node.js:

    version: '3'
    services:
      web:
        build: ./frontend
        ports:
          - "3000:3000"
      api:
        build: ./backend
        ports:
          - "4000:4000"
   

Considerações Finais

Docker representa mais do que uma simples ferramenta; é um catalisador para a inovação e eficiência na entrega de software. Ao adotar Docker, as equipes de desenvolvimento podem acelerar o ciclo de vida do desenvolvimento, melhorar a consistência operacional e reduzir os custos de infraestrutura.

Em resumo, Docker não é apenas sobre contêineres; é sobre capacitar equipes de desenvolvimento a alcançar novos níveis de desempenho e escalabilidade. Comece sua jornada com Docker hoje e descubra como essa tecnologia transformará seu fluxo de trabalho de desenvolvimento para melhor.

Este artigo foi projetado não apenas para explicar os conceitos fundamentais do Docker, mas também para engajar e educar seus leitores sobre o poder desta ferramenta inovadora. Ao otimizar para SEO, garantimos que este conteúdo seja descoberto por aqueles que buscam entender melhor Docker e suas aplicações práticas.

Se você está pronto para embarcar na revolução Docker, comece agora mesmo e prepare-se para transformar sua abordagem de desenvolvimento de software.

Introdução:

O MongoDB Compass é uma ferramenta gráfica poderosa que facilita a exploração e manipulação de bancos de dados MongoDB. Com recursos intuitivos e flexíveis, o Compass oferece visualizações detalhadas de esquemas, métricas de desempenho em tempo real e capacidades avançadas de consulta.

Acesse o site oficial do MongoDB Compass em https://www.mongodb.com/docs/compass/master/install/

Passo 1: Download MongoDB Compass

wget https://downloads.mongodb.com/compass/mongodb-compass_1.43.0_amd64.deb

Passo 2: Install MongoDB Compass

sudo dpkg -i mongodb-compass_1.43.0_amd64.deb

Passo 3: Start MongoDB Compass

mongodb-compass

Passo 4: Configurar o MongoDB Compass
Ao iniciar o MongoDB Compass pela primeira vez, você será guiado por um processo de configuração inicial para definir suas preferências, como idioma e tema da interface. Siga as instruções na tela para concluir a configuração.

Passo 5: Usar o MongoDB Compass
Com o MongoDB Compass instalado e configurado, você está pronto para explorar seus bancos de dados MongoDB, examinar esquemas, executar consultas avançadas e muito mais.

Conclusão:

Lembre-se de que o MongoDB Compass está disponível em diferentes versões, atendendo a diferentes necessidades. Certifique-se de escolher a versão correta durante o processo de download.

Espero que este tutorial seja útil para você começar a usar o MongoDB Compass no Linux. Se tiver alguma dúvida, não hesite em perguntar.

Introdução

O deploy de uma aplicação Laravel envolve a implantação da aplicação em um ambiente de produção, onde os usuários podem acessá-la. É um processo crucial que requer cuidado e atenção para garantir que a aplicação seja implantada de forma segura e eficiente.

Pré-requisitos

Antes de iniciar o processo de deploy, certifique-se de que sua aplicação Laravel está pronta para produção. Isso inclui:

• Otimização do ambiente de produção, como configurar o servidor web (por exemplo, Nginx ou Apache) e o servidor de aplicação (por exemplo, PHP-FPM).

• Configuração do arquivo .env com as variáveis de ambiente corretas para o ambiente de produção.

• Execução de testes automatizados para garantir que a aplicação esteja livre de bugs.

Opções de Hospedagem

Existem várias opções disponíveis para hospedar uma aplicação Laravel em um ambiente de produção:

1. Servidores VPS (Virtual Private Server): Como DigitalOcean, Linode, AWS EC2.

2. Plataformas de Hospedagem Gerenciada: Como Heroku, Laravel Forge, Platform.sh.

3. Serviços de Hospedagem Compartilhada: Como SiteGround, Bluehost, HostGator.

Escolha a opção de hospedagem que melhor atenda às necessidades da sua aplicação e às suas preferências de configuração e gerenciamento.

Processo de Deploy

O processo de deploy de uma aplicação Laravel geralmente envolve os seguintes passos:

1. Preparação do Ambiente de Produção: Configure o servidor e o ambiente de produção para hospedar a aplicação Laravel.

2. Transferência dos Arquivos: Envie os arquivos da aplicação Laravel para o servidor de produção usando SSH, FTP ou ferramentas de deploy automatizadas.

3. Instalação de Dependências: No servidor de produção, execute composer install para instalar as dependências do Laravel.

4. Configuração do Arquivo .env: Certifique-se de configurar o arquivo .env com as variáveis de ambiente corretas para o ambiente de produção.

5. Execução de Migrações e Seeders: Se necessário, execute migrações e seeders no banco de dados do servidor de produção para garantir que esteja atualizado.

6. Configuração do Servidor Web: Configure o servidor web (Nginx, Apache) para direcionar as solicitações HTTP para o diretório público da aplicação Laravel.

7. Configuração do Cache e das Filas: Configure o cache e as filas de trabalhos para otimizar o desempenho da aplicação em produção.

8. Monitoramento e Manutenção: Implemente ferramentas de monitoramento e agende manutenções regulares para garantir a integridade e a disponibilidade contínua da aplicação em produção.

Conclusão

O deploy de uma aplicação Laravel é um processo importante que requer planejamento, preparação e execução cuidadosa. Ao seguir as práticas recomendadas e escolher a opção de hospedagem adequada, você pode implantar sua aplicação Laravel com confiança e garantir que ela esteja disponível para seus usuários de forma segura e eficiente. Nos próximos tópicos, continuaremos explorando outros aspectos avançados do desenvolvimento web com o Laravel.

Introdução

Os testes automatizados são essenciais para garantir a qualidade e a estabilidade de uma aplicação. No Laravel, você pode escrever e executar uma variedade de testes automatizados para verificar se o seu código está funcionando conforme o esperado.

Tipos de Testes

O Laravel suporta vários tipos de testes automatizados, incluindo Testes Unitários, Testes de Integração e Testes de Ponta a Ponta (End-to-End).

Testes Unitários

Os Testes Unitários verificam se unidades individuais de código (como métodos de classe) funcionam conforme o esperado. Eles são rápidos de escrever e executar e ajudam a identificar bugs no código.

Testes de Integração

Os Testes de Integração verificam se componentes de uma aplicação funcionam juntos corretamente. Eles testam a interação entre várias partes do código e podem ajudar a identificar problemas de integração.

Testes de Ponta a Ponta (End-to-End)

Os Testes de Ponta a Ponta simulam a interação de um usuário com a aplicação, verificando se o sistema funciona conforme o esperado do ponto de vista do usuário final. Eles testam o fluxo completo da aplicação, desde a entrada do usuário até a saída esperada.

Escrevendo Testes no Laravel

O Laravel fornece uma API expressiva e poderosa para escrever testes automatizados.

Criando Testes

Você pode criar um novo teste usando o Artisan CLI:

php artisan make:test UserTest

Isso criará um arquivo de teste em tests/Feature ou tests/Unit, dependendo do tipo de teste que você está escrevendo.

Escrevendo Testes

Em seguida, você pode escrever os testes dentro do arquivo gerado. Por exemplo, um teste de unidade para verificar se um método retorna o resultado esperado pode ser assim:

<?php
    public function testExample()
    {
        $result = SomeClass::someMethod();

        $this->assertEquals('expected result', $result);
    }

Executando Testes

Você pode executar todos os testes usando o Artisan CLI:

php artisan test

Ou você pode executar testes em um arquivo específico:

php artisan test tests/Feature/UserTest.php

Conclusão

Os testes automatizados são uma parte fundamental do desenvolvimento de software moderno. No Laravel, você pode escrever e executar uma variedade de testes automatizados para garantir que sua aplicação funcione conforme o esperado e que novas alterações não introduzam regressões ou bugs. Com uma API expressiva e poderosa para escrever testes, o Laravel facilita a implementação de uma estratégia de teste eficaz para sua aplicação. Nos próximos tópicos, continuaremos explorando outros aspectos avançados do desenvolvimento web com o Laravel.

https://www.youtube.com/watch?v=ertkSaFs_24

Introdução

Primeiro de tudo, vamos entender o que é uma cron.

Uma cron (ou cron job) é uma tarefa agendada para executar automaticamente em determinados horários em sistemas Linux/Unix.

Ela é gerenciada por um serviço chamado cron, que roda em segundo plano (um daemon) verificando o tempo e executando comandos quando chega o horário programado.

Exemplo simples

Imagine que você quer fazer backup do banco todo dia às 2h da manhã.
Você cria uma cron job que executa um comando nesse horário automaticamente.

Exemplo de cron:

0 2 * * * php backup.php

Significa:

┌ minuto (0 - 59)
│ ┌ hora (0 - 23)
│ │ ┌ dia do mês (1 - 31)
│ │ │ ┌ mês (1 - 12)
│ │ │ │ ┌ dia da semana (0 - 7)
│ │ │ │ │
0 2 * * * comando

Ou seja:

Todo dia às 02:00 executar php backup.php

Exemplos comuns de cron jobs

• limpar arquivos temporários

• rodar backups

• enviar emails automáticos

• executar scripts de manutenção

• processar filas de jobs

Exemplo no Laravel

No Laravel, normalmente você configura uma única cron no servidor:

* * * * * sail artisan schedule:run

Isso faz o Laravel verificar a cada minuto se existe alguma tarefa agendada no:

app/Console/Kernel.php

Exemplo dentro do Laravel:

$schedule->command('emails:send')->daily();

Resumindo

Uma cron é basicamente:

Um agendador automático de tarefas no servidor.

Ele permite que programas rodem sem intervenção humana em horários específicos.

Agora vamos fazer no Laravel

https://youtu.be/BuDPsJbfl8c

Nesse tutorial, vamos ver 3 tipos de cron ou schedules no Laravel.

• Para comandos artisan

• Para jobs

• Para events

Automatizar tarefas é essencial em qualquer aplicação moderna. Envio de e-mails, processamento de dados, sincronizações, limpezas automáticas… tudo isso pode (e deve) rodar fora da requisição HTTP.

O Laravel Scheduler resolve isso de forma elegante.

Neste artigo você vai aprender:

• O que é o Scheduler

• Como agendar Commands

• Como agendar Jobs

• Como agendar Events

O que é o Laravel Scheduler?

O Scheduler permite definir tarefas agendadas diretamente no código, sem precisar criar múltiplas entradas no crontab.

Em vez disso, você configura apenas um cron no servidor, e o Laravel decide o que deve rodar.

Arquivo principal:

app/Console/Kernel.php

Comandos úteis

- sail artisan                = Lista todos os comandos CLI
- sail artisan schedule:list  = Lista todas as tarefas agendadas
- sail artisan schedule:work  = Inicia o agendador de tarefas
- sail artisan schedule:run   = Roda todos os comandos agendados
- sail artisan queue:work     = Inicia o processamento de tarefas na fila como um daemon 
- sail artisan horizon        = Ativa o pacote do horizon
- sail artisan horizon:status = Obtenha o status atual do Horizon
- sail artisan horizon:clear  = Excluir todos os trabalhos da fila especificada

Criando um job
- sail artisan make:job TestJob

Criando um event
- sail artisan make:listener TestListener 


OBS: (daemon: é um programa que roda em segundo plano no sistema operacional, executando tarefas automaticamente sem interação direta do usuário.)

Exemplo 1 — Agendando Commands Artisan

Criando comando via terminal:

php artisan make:command TestCommand

<?php

// Arquivo criado: app/Console/Commands/TestCommand.php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\Log;

class TestCommand extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'app:test-command';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Execute the console command.
     */
    public function handle()
    {
        Log::info('Test command in TestCommand.php');
    }
}

Defina o signature:

protected $signature = 'app:test-command';
protected $description = 'Command description';

Agendando o Command
No Kernel.php:

 protected function schedule(Schedule $schedule)
 {
   // Command defined in app/Console/Commands/TestCommand.php
   $schedule->command('app:test-command')->everyMinute();
 }

https://www.youtube.com/watch?v=qi6W28YfMXU

Exemplo 2 — Agendando Commands Artisan

No routes/console.php:

// Arquivo: routes/console.php copie e cole o código:

Artisan::command('app:my-teste', function () {
    Log::info('Test command in console.php');
})->purpose('Test command in console.php');

No Kernel.php:

<?php
    

    use Illuminate\Console\Scheduling\Schedule;
    
    protected function schedule(Schedule $schedule)
    {
        // Command defined in rotas/console.php
        $schedule->command('app:my-teste')->when(function () {
            return User::count() > 0;
        })->everyMinute();
    }

Exemplo 3 — Criando um Job

php artisan make:job TestJob

// Arquivo: app/jobs/TestJob.php

public function handle(): void
{
   Log::info('Test job executed at ' . now());
}

Arquivo kernel.php:

<?php
    use Illuminate\Console\Scheduling\Schedule;
    
    protected function schedule(Schedule $schedule)
    {
        // Job defined in app/Jobs/TestJob.php
        $schedule->job(TestJob::class)->everyMinute();
    }

Isso significa:

• A cada minuto é executado

• O job é enviado para a fila (Queue)

• Worker processa em background

Execute no terminal:

sail artisan schedule:list 

Lista todas as tarefas agendadas.

sail artisan schedule:work

Inicia o trabalhador agendado

https://www.youtube.com/watch?v=H4sTONx9Mio

Exemplo 4 — Agendando um event

No arquivo Providers/EventServiceProvider.php adicione:

protected $listen = [
   Registered::class => [
     SendEmailVerificationNotification::class,
   ],
   ScheduledTaskStarting::class => [
     TestListener::class,
   ],
],

Criando um listener:

php artisan make:listener TestListener

<?php

namespace App\Listeners;

use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Support\Facades\Log;

class TestListener
{
    /**
     * Create the event listener.
     */
    public function __construct()
    {
        //
    }

    /**
     * Handle the event.
     */
    public function handle(object $event): void
    {
        Log::info('TestListener handled event: ' . get_class($event) . ' at ' . now());
    }
}

Na pasta Providers tem um arquivo chamado: EventServiceProvider.php

<?php
// File in app/Providers/EventServiceProvider.php
namespace App\Providers;

use App\Listeners\TestListener;
use Illuminate\Auth\Events\Registered;
use Illuminate\Auth\Listeners\SendEmailVerificationNotification;
use Illuminate\Console\Events\ScheduledTaskStarting;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Event;
use PHPUnit\Metadata\Test;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event to listener mappings for the application.
     *
     * @var array<class-string, array<int, class-string>>
     */
    protected $listen = [
        Registered::class => [
            SendEmailVerificationNotification::class,
        ],
        ScheduledTaskStarting::class => [
            TestListener::class,
        ],
    ];

    /**
     * Register any events for your application.
     */
    public function boot(): void
    {
        //
    }

    /**
     * Determine if events and listeners should be automatically discovered.
     */
    public function shouldDiscoverEvents(): bool
    {
        return false;
    }
}

Defina a classe do evento criado dentro de ScheduledTaskStarting

ScheduledTaskStarting::class => [
 TestListener::class,
],

Execute:

sail artisan schedule:run

Agora veja o evento sendo executado no log.

Arquivo kernel.php completo:

<?php

namespace App\Console;

use App\Jobs\TestJob;
use App\Models\User;
use Illuminate\Console\Scheduling\Schedule;
use Illuminate\Foundation\Console\Kernel as ConsoleKernel;
use Illuminate\Support\Facades\Log;

class Kernel extends ConsoleKernel
{
    /**
     * Define the application's command schedule.
     */
    protected function schedule(Schedule $schedule): void
    {
        // Command defined in app/Console/Commands/TestCommand.php
        $schedule->command('app:test-command')->everyMinute();

        // Command defined in rotas/console.php
        $schedule->command('app:my-teste')->when(function () {
            return User::count() > 0;
        })->everyMinute();

        // Job defined in app/Jobs/TestJob.php
        $schedule->job(TestJob::class)->everyMinute();

    }

    /**
     * Register the commands for the application.
     */
    protected function commands(): void
    {
        $this->load(__DIR__.'/Commands');

        require base_path('routes/console.php');
    }
}

No arquivo de log, podemos visualizar todos os logs que definimos no código. local: storage/laravel.log

Links importantes:

crontab.cronhub.io
documentação do laravel

Conclusão

O Laravel Scheduler centraliza e organiza a automação de tarefas da aplicação.
Ele torna o código mais limpo, evita configurações manuais no servidor e facilita a manutenção.

Quando combinado com Jobs, ele permite criar sistemas automatizados, escaláveis e robustos de forma elegante.

Introdução

Ao desenvolver APIs com Laravel, um dos pontos mais importantes é garantir que apenas usuários autorizados consigam acessar determinados endpoints. Para isso, o Laravel oferece o Laravel Sanctum, uma solução simples, moderna e oficial para autenticação de APIs e aplicações SPA.

O Sanctum foi criado para resolver dois cenários muito comuns:

• Autenticação de APIs via tokens

• Autenticação de SPAs (Single Page Applications) usando cookies e sessão

Diferente de soluções mais complexas como OAuth2 (Laravel Passport), o Sanctum foca em simplicidade, segurança e produtividade, sendo ideal para a maioria dos projetos.

Neste tutorial, você vai entender como o Sanctum funciona, as diferenças entre os tipos de autenticação e como instalá-lo corretamente em um projeto Laravel.

Como funciona o Laravel Sanctum

O Laravel Sanctum funciona oferecendo uma camada de autenticação baseada em dois conceitos principais:

🔐 Tokens pessoais (Personal Access Tokens)

• Cada usuário pode ter um ou vários tokens

• Cada token é armazenado no banco de dados

• O cliente envia o token no header Authorization: Bearer

Internamente:

• O token é gerado uma única vez (plain text)

• Apenas o hash do token é salvo no banco

• O Laravel valida automaticamente o token a cada requisição

🍪 Autenticação baseada em cookies (SPA)

• Usa sessões do Laravel

• Proteção automática contra CSRF

• Ideal para aplicações frontend (React, Vue, etc.)

Nesse modo:

• O frontend solicita um cookie CSRF

• O login cria uma sessão autenticada

• As requisições seguintes usam cookies HttpOnly

O grande diferencial do Sanctum é permitir esses dois fluxos no mesmo projeto, sem conflito.

Diferença entre Tokens de API e Autenticação SPA

Essa é uma das partes mais importantes de entender antes de usar o Sanctum.

🔹 Tokens de API

Indicado para:

• Aplicativos mobile

• Integrações de terceiros

• APIs públicas ou privadas

• Sistemas externos

Características:

• Stateless (sem sessão)

• Token enviado no header

• Fácil de testar com Postman / Insomnia

• Pode ter permissões (abilities)

Exemplo de header:

Authorization: Bearer 1|xYzAbC123...

🔹 Autenticação SPA (Cookies)

Indicado para:

• React, Vue, Angular

• Frontend no mesmo domínio ou subdomínio

• Aplicações web modernas

Características:

• Usa sessão do Laravel

• Cookies HttpOnly

• Proteção CSRF

• Mais seguro contra XSS

Fluxo resumido:

1. /sanctum/csrf-cookie

2. /login

3. Requisições autenticadas automaticamente

🧠 Comparação rápida

As versões mais recentes do Laravel já incluem o Laravel Sanctum. No entanto, se o arquivo composer.json da sua aplicação não incluir o pacote laravel/sanctum, você pode seguir as instruções de instalação abaixo.

Instalação – Passo a passo

⚠️ Observação: Neste projeto, o Sanctum já está presente no composer.json, então não é necessário rodar composer require laravel/sanctum.

Passo 1 – Verificar dependência no composer.json:

"laravel/sanctum": "^3.3"

Se estiver presente, o pacote já está instalado.

Passo 2 – Publicar configurações

php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"

Isso cria:

• config/sanctum.php

• migrations necessárias

Passo 3 – Rodar as migrations

php artisan migrate

Será criada a tabela:

• personal_access_tokens

Passo 4 – Configurar o Model User

No arquivo app/Models/User.php:

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasApiTokens;
}

Sem esse trait, não é possível gerar tokens.

Passo 5 – Proteger rotas da API

Em routes/api.php:

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
    return $request->user();
});

Agora essa rota só pode ser acessada por usuários autenticados via Sanctum.

Conclusão

O Laravel Sanctum é uma solução poderosa e simples para autenticação moderna em APIs e SPAs. Ele elimina complexidades desnecessárias e cobre a maioria dos casos reais de mercado.

Se você precisa:

• Proteger APIs

• Integrar com frontend moderno

• Trabalhar com tokens de forma segura

👉 O Sanctum é a escolha certa.

Introdução

Ao construir uma aplicação web, é fundamental validar os dados que são submetidos pelos usuários. O Laravel oferece uma maneira fácil e eficaz de lidar com validação de dados através de Requests e de recursos integrados para validação.

Criando Requests

Requests são classes que encapsulam a lógica de validação de dados de entrada. Elas são usadas para validar os dados que são submetidos através de formulários HTTP.

Criando um Request

Você pode criar uma nova classe de Request usando o Artisan CLI:

php artisan make:request StorePostRequest

Isso criará um arquivo de Request em app/Http/Requests.

Definindo Regras de Validação

Dentro da classe de Request, você pode definir as regras de validação no método rules:

<?php
    public function rules()
    {
        return [
            'title' => 'required|string|max:255',
            'body' => 'required|string',
        ];
    }

Usando o Request

Para usar o Request em um controlador, basta injetá-lo no método desejado:

<?php
    use App\Http\Requests\StorePostRequest;

    public function store(StorePostRequest $request)
    {
        // Se chegar até aqui, os dados são válidos
        // Lógica para salvar o post
    }

Exibindo Mensagens de Erro

O Laravel fornece recursos para exibir mensagens de erro personalizadas quando a validação falha.

Exibindo Erros na View

Você pode exibir mensagens de erro diretamente na view usando a função @error:

<?php
    <input type="text" name="title" value="{{ old('title') }}">
    @error('title')
        <div class="alert alert-danger">{{ $message }}</div>
    @enderror

Redirecionando com Mensagens de Erro

Ao redirecionar de volta ao formulário com mensagens de erro, você pode usar o método withErrors:

<?php
    return redirect('/form')
        ->withErrors($validator)
        ->withInput();

Validação em Controller

Você também pode validar dados diretamente nos métodos dos controladores, sem a necessidade de criar uma classe de Request separada.

Validação no Controller

Você pode validar os dados diretamente no método do controlador usando o facade Validator:

<?php
  use Illuminate\Support\Facades\Validator;

  public function store(Request $request)
  {
        $validator = Validator::make($request->all(), [
            'title' => 'required|string|max:255',
            'body' => 'required|string',
        ]);

        if ($validator->fails()) {
            return redirect('/form')
                ->withErrors($validator)
                ->withInput();
        }

        // Lógica para salvar o post
   }

Conclusão

Requests e Validação são partes essenciais do processo de desenvolvimento de uma aplicação web segura e funcional. O Laravel oferece uma maneira fácil e eficiente de validar os dados de entrada dos usuários, garantindo que apenas dados válidos sejam aceitos e processados pela aplicação. Ao utilizar Requests e as funcionalidades integradas de validação do Laravel, você pode construir uma aplicação robusta e confiável que oferece uma experiência de usuário consistente e livre de erros. Nos próximos tópicos, continuaremos explorando as poderosas ferramentas e recursos do Laravel para construir aplicações web incríveis.

Proteja sua Aplicação com Autorizações

Criando Políticas

Políticas são classes que organizam a lógica de autorização em torno de um modelo ou recurso específico. Por exemplo, se seu aplicativo for um blog, você poderá ter um modelo App\Models\Post e um App\Policies\PostPolicy correspondente para autorizar ações do usuário, como criar ou atualizar postagens.

Você pode gerar uma política usando o comando make:policy Artisan. A política gerada será colocada no diretório app/Policies. Se este diretório não existir em sua aplicação, o Laravel irá criá-lo para você:

sail artisan make:policy PostPolicy

O comando make:policy irá gerar uma classe de política vazia. Se você quiser gerar uma classe com exemplos de métodos de política relacionados à visualização, criação, atualização e exclusão do recurso, você pode fornecer uma opção --model ao executar o comando:

sail artisan make:policy PostPolicy --model=Post

Registrando Políticas

Depois que a classe de política for criada, ela precisará ser registrada.
Registrar políticas é como podemos informar ao Laravel qual política usar ao autorizar ações contra um determinado tipo de modelo.

O App\Providers\AuthServiceProvider incluído nas novas aplicações Laravel contém uma propriedade de políticas que mapeia seus modelos Eloquent para suas políticas correspondentes. Registrar uma política instruirá o Laravel qual política utilizar ao autorizar ações contra um determinado modelo do Eloquent:

<?php

namespace App\Providers;

use App\Models\Post;
use App\Policies\PostPolicy;
use Illuminate\Foundation\Support\Providers\AuthServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Gate;

class AuthServiceProvider extends ServiceProvider
{
    /**
     * The policy mappings for the application.
     *
     * @var array
     */
    protected $policies = [
        Post::class => PostPolicy::class,
    ];

    /**
     * Register any application authentication / authorization services.
     */
    public function boot(): void
    {
        // ...
    }
}

Escrevendo Políticas

Métodos de política

Depois que a classe de política for registrada, você poderá adicionar métodos para cada ação que ela autorizar. Por exemplo, vamos definir um método de atualização em nossa PostPolicy que determina se um determinado App\Models\User pode atualizar uma determinada instância de App\Models\Post.

O método update receberá uma instância User e uma Post como argumentos e deverá retornar verdadeiro ou falso indicando se o usuário está autorizado a atualizar o Post fornecido. Portanto, neste exemplo, verificaremos se o id do usuário corresponde ao user_id da postagem:

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     */
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

Você pode continuar a definir métodos adicionais na política conforme necessário para as diversas ações que ela autoriza. Por exemplo, você pode definir métodos de visualização ou exclusão para autorizar várias ações relacionadas à postagem, mas lembre-se de que você é livre para dar aos seus métodos de política o nome que desejar.

Se você usou a opção --model ao gerar sua política por meio do console Artisan, ela já conterá métodos para as ações viewAny, view, create, update, delete, restore e forceDelete.

Policy Responses

Até agora, examinamos apenas métodos de política que retornam valores booleanos simples. No entanto, às vezes você pode desejar retornar uma resposta mais detalhada, incluindo uma mensagem de erro. Para fazer isso, você pode retornar uma instância Illuminate\Auth\Access\Response do seu método de política:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
                ? Response::allow()
                : Response::deny('You do not own this post.');
}

Ao retornar uma resposta de autorização da sua política, o método Gate::allows ainda retornará um valor booleano simples; entretanto, você pode usar o método Gate::inspect para obter a resposta de autorização completa retornada pelo portão:

use Illuminate\Support\Facades\Gate;

$response = Gate::inspect('update', $post);

if ($response->allowed()) {
    // The action is authorized...
} else {
    echo $response->message();
}

Ao usar o método Gate::authorize, que lança uma AuthorizationException se a ação não for autorizada, a mensagem de erro fornecida pela resposta de autorização será propagada para a resposta HTTP:

Gate::authorize('update', $post);

// The action is authorized...

Personalizando o status da resposta HTTP

Quando uma ação é negada por meio de um método de política, uma resposta HTTP 403 é retornada; entretanto, às vezes pode ser útil retornar um código de status HTTP alternativo. Você pode personalizar o código de status HTTP retornado para uma verificação de autorização com falha usando o construtor estático denyWithStatus na classe Illuminate\Auth\Access\Response:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
                ? Response::allow()
                : Response::denyWithStatus(404);
}

Como ocultar recursos por meio de uma resposta 404 é um padrão comum para aplicações web, o método denyAsNotFound é oferecido por conveniência:

use App\Models\Post;
use App\Models\User;
use Illuminate\Auth\Access\Response;

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post): Response
{
    return $user->id === $post->user_id
                ? Response::allow()
                : Response::denyAsNotFound();
}

Métodos sem modelos

Alguns métodos de política recebem apenas uma instância do usuário atualmente autenticado. Esta situação é mais comum ao autorizar ações de criação. Por exemplo, se você estiver criando um blog, talvez queira determinar se um usuário está autorizado a criar postagens. Nessas situações, seu método de política deverá esperar receber apenas uma instância de usuário:

/**
 * Determine if the given user can create posts.
 */
public function create(User $user): bool
{
    return $user->role == 'writer';
}

Usuários convidados

Por padrão, todos os gates e políticas retornam automaticamente falso se a solicitação HTTP recebida não tiver sido iniciada por um usuário autenticado.

No entanto, você pode permitir que essas verificações de autorização passem para seus gates e policies declarando uma dica de tipo "opcional" ou fornecendo um valor padrão nulo para a definição do argumento do usuário:

<?php

namespace App\Policies;

use App\Models\Post;
use App\Models\User;

class PostPolicy
{
    /**
     * Determine if the given post can be updated by the user.
     */
    public function update(?User $user, Post $post): bool
    {
        return $user?->id === $post->user_id;
    }
}

Filtros de política

Para determinados usuários, você pode autorizar todas as ações dentro de uma determinada política. Para fazer isso, defina um método before na política.
O método before será executado antes de qualquer outro método na política, dando a você a oportunidade de autorizar a ação antes que o método de política pretendido seja realmente chamado. Este recurso é mais comumente usado para autorizar administradores de aplicativos a executar qualquer ação:

use App\Models\User;

/**
 * Perform pre-authorization checks.
 */
public function before(User $user, string $ability): bool|null
{
    if ($user->isAdministrator()) {
        return true;
    }

    return null;
}

Se desejar negar todas as verificações de autorização para um tipo específico de usuário, você poderá retornar false do método before. Se null for retornado, a verificação de autorização passará para o método de política.

O método before de uma classe de política não será chamado se a classe não contiver um método com um nome correspondente ao nome da habilidade que está sendo verificada.

Autorizando ações usando políticas

Através do modelo de usuário

O modelo App\Models\User incluído em sua aplicação Laravel inclui dois métodos úteis para autorizar ações: can e cannot. Os métodos can e cannot não recebem o nome da ação que você deseja autorizar e o modelo relevante. Por exemplo, vamos determinar se um usuário está autorizado a atualizar um determinado modelo App\Models\Post. Normalmente, isso será feito dentro de um método de controlador:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Update the given post.
     */
    public function update(Request $request, Post $post): RedirectResponse
    {
        if ($request->user()->cannot('update', $post)) {
            abort(403);
        }

        // Update the post...

        return redirect('/posts');
    }
}

Se uma política for registrada para um determinado modelo, o método can chamará automaticamente a política apropriada e retornará o resultado booleano. Se nenhuma política for registrada para o modelo, o método can tentará chamar o Gate baseado em fechamento correspondente ao nome da ação fornecido.

Ações que não requerem modelos

Lembre-se, algumas ações podem corresponder a métodos de política como create que não requerem uma instância de modelo. Nessas situações, você pode passar um nome de classe para o método can. O nome da classe será usado para determinar qual política usar ao autorizar a ação:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Create a post.
     */
    public function store(Request $request): RedirectResponse
    {
        if ($request->user()->cannot('create', Post::class)) {
            abort(403);
        }

        // Create the post...

        return redirect('/posts');
    }
}

Via Controller Helpers

Além dos métodos úteis fornecidos para o modelo App\Models\User, o Laravel fornece um método de autorização útil para qualquer um dos seus controladores que estendem a classe base App\Http\Controllers\Controller.

Assim como o método can, este método aceita o nome da ação que você deseja autorizar e o modelo relevante. Se a ação não for autorizada, o método authorize lançará uma exceção Illuminate\Auth\Access\AuthorizationException que o manipulador de exceção do Laravel converterá automaticamente em uma resposta HTTP com um código de status 403:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Update the given blog post.
     *
     * @throws \Illuminate\Auth\Access\AuthorizationException
     */
    public function update(Request $request, Post $post): RedirectResponse
    {
        $this->authorize('update', $post);

        // The current user can update the blog post...

        return redirect('/posts');
    }
}

Ações que não requerem modelos

Conforme discutido anteriormente, alguns métodos de política como create não requerem uma instância de modelo. Nessas situações, você deve passar um nome de classe para o método de autorização. O nome da classe será usado para determinar qual política usar ao autorizar a ação:

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

/**
 * Create a new blog post.
 *
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function create(Request $request): RedirectResponse
{
    $this->authorize('create', Post::class);

    // The current user can create blog posts...

    return redirect('/posts');
}

Autorizando Controladores de Recursos

Se você estiver utilizando controladores de recursos, poderá usar o método authorizeResource no construtor do seu controlador. Este método anexará as definições de middleware apropriadas aos métodos do controlador de recursos.

O método authorizeResource aceita o nome da classe do modelo como seu primeiro argumento, e o nome do parâmetro de rota/solicitação que conterá o ID do modelo como seu segundo argumento. Você deve garantir que seu controlador de recursos seja criado usando o sinalizador --model para que ele tenha as assinaturas de método e dicas de tipo necessárias:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Models\Post;

class PostController extends Controller
{
    /**
     * Create the controller instance.
     */
    public function __construct()
    {
        $this->authorizeResource(Post::class, 'post');
    }
}

Os seguintes métodos de controlador serão mapeados para seu método de política correspondente. Quando as solicitações são roteadas para um determinado método do controlador, o método de política correspondente será automaticamente invocado antes que o método do controlador seja executado:

Você pode usar o comando make:policy com a opção --model para gerar rapidamente uma classe de política para um determinado modelo:

sail artesão make:policy PostPolicy --model=Post

Através de Middleware

O Laravel inclui um middleware que pode autorizar ações antes mesmo que a solicitação recebida chegue às suas rotas ou controladores. Por padrão, o middleware Illuminate\Auth\Middleware\Authorize recebe a chave can em sua classe App\Http\Kernel Vamos explorar um exemplo de uso do middleware can para autorizar que um usuário possa atualizar uma postagem:

use App\Models\Post;

Route::put('/post/{post}', function (Post $post) {
    // The current user may update the post...
})->middleware('can:update,post');

Neste exemplo, estamos passando dois argumentos ao middleware can. O primeiro é o nome da ação que desejamos autorizar e o segundo é o parâmetro de rota que desejamos passar para o método de política. Nesse caso, como estamos usando vinculação de modelo implícita, um modelo App\Models\Post será passado para o método de política. Caso o usuário não esteja autorizado a realizar a ação determinada, uma resposta HTTP com código de status 403 será retornada pelo middleware.

Por conveniência, você também pode anexar o middleware can à sua rota usando o método can:

use App\Models\Post;

Route::put('/post/{post}', function (Post $post) {
    // The current user may update the post...
})->can('update', 'post');

Ações que não requerem modelos

Novamente, alguns métodos de política como create não requerem uma instância de modelo. Nessas situações, você pode passar um nome de classe para o middleware. O nome da classe será usado para determinar qual política usar ao autorizar a ação:

Route::post('/post', function () {
    // The current user may create posts...
})->middleware('can:create,App\Models\Post');

Especificar o nome inteiro da classe em uma definição de middleware de string pode se tornar complicado. Por esse motivo, você pode optar por anexar o middleware can à sua rota usando o método can:

use App\Models\Post;

Route::post('/post', function () {
    // The current user may create posts...
})->can('create', Post::class);

Via Blade Templates

Ao escrever modelos Blade, você pode desejar exibir uma parte da página somente se o usuário estiver autorizado a executar uma determinada ação. Por exemplo, você pode querer mostrar um formulário de atualização para uma postagem de blog apenas se o usuário puder realmente atualizar a postagem. Nesta situação, você pode usar as diretivas @can e @cannot:

@can('update', $post)
    <!-- The current user can update the post... -->
@elsecan('create', App\Models\Post::class)
    <!-- The current user can create new posts... -->
@else
    <!-- ... -->
@endcan

@cannot('update', $post)
    <!-- The current user cannot update the post... -->
@elsecannot('create', App\Models\Post::class)
    <!-- The current user cannot create new posts... -->
@endcannot

Essas diretivas são atalhos convenientes para escrever instruções @if e @unless. As declarações @can e @cannot acima são equivalentes às seguintes declarações:

@if (Auth::user()->can('update', $post))
    <!-- The current user can update the post... -->
@endif

@unless (Auth::user()->can('update', $post))
    <!-- The current user cannot update the post... -->
@endunless

Você também pode determinar se um usuário está autorizado a executar qualquer ação de um determinado conjunto de ações. Para fazer isso, use a diretiva @canany:

@canany(['update', 'view', 'delete'], $post)
    <!-- The current user can update, view, or delete the post... -->
@elsecanany(['create'], \App\Models\Post::class)
    <!-- The current user can create a post... -->
@endcanany

Ações que não requerem modelos

Como a maioria dos outros métodos de autorização, você pode passar um nome de classe para as diretivas @can e @cannot se a ação não exigir uma instância de modelo:

@can('create', App\Models\Post::class)
    <!-- The current user can create posts... -->
@endcan

@cannot('create', App\Models\Post::class)
    <!-- The current user can't create posts... -->
@endcannot

Fornecendo Contexto Adicional

Ao autorizar ações usando políticas, você pode passar um array como segundo argumento para as diversas funções de autorização e auxiliares. O primeiro elemento da matriz será usado para determinar qual política deve ser invocada, enquanto o restante dos elementos da matriz são passados ​​como parâmetros para o método de política e podem ser usados ​​para contexto adicional ao tomar decisões de autorização. Por exemplo, considere a seguinte definição de método PostPolicy que contém um parâmetro $category adicional:

/**
 * Determine if the given post can be updated by the user.
 */
public function update(User $user, Post $post, int $category): bool
{
    return $user->id === $post->user_id &&
           $user->canUpdateCategory($category);
}

Ao tentar determinar se o usuário autenticado pode atualizar uma determinada postagem, podemos invocar este método de política da seguinte forma:

/**
 * Update the given blog post.
 *
 * @throws \Illuminate\Auth\Access\AuthorizationException
 */
public function update(Request $request, Post $post): RedirectResponse
{
    $this->authorize('update', [$post, $request->category]);

    // The current user can update the blog post...

    return redirect('/posts');
}

Conclusão

Implementar autenticação e autorização no Laravel é uma tarefa simplificada graças às ferramentas e funcionalidades integradas do framework. Com o sistema de autenticação básico e proteção de rotas com middleware, você pode garantir que sua aplicação esteja segura e que os usuários tenham acesso apropriado às diferentes partes do sistema. Nos próximos tópicos, exploraremos outras funcionalidades do Laravel para continuar aprimorando suas habilidades no desenvolvimento de aplicações robustas e eficientes.

Requisitos

Código das Migrations:

Schema::create('posts', function (Blueprint $table) {
   $table->id();
   $table->foreignId('user_id')->constrained()->onDelete('cascade');
   $table->string('title');
   $table->text('content');
   $table->timestamps();
});

Execute:

sail artisan migrate

Banco de dados

Seeder

sail artisan make:seeder UsersTableSeeder
sail artisan make:seeder PostsTableSeeder

UsersTableSeeder

use Illuminate\Support\Facades\DB;

DB::table('users')->insert([
    [
      'name' => 'areadev',
      'email' => 'areadev@gmail.com',
      'password' => Hash::make('12341234'),
    ],
    [
      'name' => 'bruno',
      'email' => 'bruno@gmail.com',
      'password' => Hash::make('12341234'),
     ],
]);

PostsTableSeeder

use Illuminate\Support\Facades\DB;

// Obter o ID dos usuários
$userIds = DB::table('users')->pluck('id');

// Criar posts para cada usuário
foreach ($userIds as $userId) {
   DB::table('posts')->insert([
    [
      'user_id' => $userId,
      'title' => 'Post Title ' . $userId . ' - 1',
      'content' => 'This is the content for post 1 of user ' . $userId,
    ],
    [
      'user_id' => $userId,
      'title' => 'Post Title ' . $userId . ' - 2',
      'content' => 'This is the content for post 2 of user ' . $userId,
     ],
    ]);
}

DatabaseSeeder

$this->call([
  FruitsTableSeeder::class,
  UsersTableSeeder::class,
  PostsTableSeeder::class,
]);

Model User

/* adicione o seguinte código no final do arquivo. */

/**
 * Get the posts for the user.
 */
public function posts()
{
  return $this->hasMany(Post::class);
}

Model Post

protected $fillable = [
    'user_id',
    'title',
    'content',
];

/**
 * Get the user that owns the post.
 */
public function user()
{
   return $this->belongsTo(User::class);
}

Objetivo

Implementar sistemas de autenticação e autorização para proteger e gerenciar o acesso à aplicação é crucial para qualquer aplicação web. No Laravel, essas funcionalidades são integradas de maneira eficiente e segura, permitindo que você configure e gerencie o acesso dos usuários com facilidade.

Authorization

Além de fornecer serviços de autenticação integrados, o Laravel também fornece uma maneira simples de autorizar ações do usuário em um determinado recurso.

Por exemplo, mesmo que um usuário seja autenticado, ele pode não estar autorizado a atualizar ou excluir determinados modelos do Eloquent ou registros de banco de dados gerenciados pela sua aplicação. Os recursos de autorização do Laravel fornecem uma maneira fácil e organizada de gerenciar esses tipos de verificações de autorização.

O Laravel fornece duas formas principais de autorizar ações: gates e policies.
Pense em gates e policies como rotas e controladores.

Gates fornece uma abordagem simples e baseada em fechamento para autorização, enquanto políticas, como controladores, agrupam lógica em torno de um modelo ou recurso específico.

Você não precisa escolher entre usar exclusivamente gates ou usar exclusivamente policies ao criar um aplicativo. A maioria dos aplicativos provavelmente conterá alguma mistura de gates e policies, e isso é perfeitamente normal!

Gates são mais aplicáveis ​​a ações que não estão relacionadas a nenhum modelo ou recurso, como visualizar um painel de administrador. Por outro lado, as políticas devem ser utilizadas quando se deseja autorizar uma ação para um modelo ou recurso específico.

Gates

Gates são simplesmente fechamentos que determinam se um usuário está autorizado a realizar uma determinada ação. Normalmente, os gates são definidos no método de inicialização da classe App\Providers\AuthServiceProvider usando a facade Gate.

Gates sempre recebe uma instância de usuário como seu primeiro argumento e pode opcionalmente receber argumentos adicionais, como um modelo Eloquent relevante.

Neste exemplo, definiremos um gate para determinar se um usuário pode atualizar um determinado modelo App\Models\Post. O gate fará isso comparando o id do usuário com o user_id do usuário que criou a postagem:

use App\Models\Post;
use App\Models\User;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Gate;

class AppServiceProvider extends ServiceProvider
{ 
    /**
     * The policy mappings for the application.
     * As políticas são registradas em um array associativo.
     * Onde a chave é o modelo e o valor é a classe da política.
     * @var array<class-string, class-string>
     */
    protected $policies = [
        // 'App\Models\Model' => 'App\Policies\ModelPolicy',
    ];


    /**
     * Register any authentication / authorization services.
     */
    public function boot(): void
    {
       /**
        * define um Gate, que é uma maneira de verificar se um usuário tem permissão para realizar uma ação específica.
        * A função anônima (closure) que você fornece define a lógica de autorização. Ela recebe dois parâmetros: um User e um Post.
        *
        * Parâmetros:
        *  User $user: O usuário que está tentando realizar a ação.
        *  Post $post: O modelo Post sobre o qual a ação está sendo realizada.
        */
       Gate::define('update-post', function (User $user, Post $post) {
         return $user->id === $post->user_id;
        });
    }
}

Assim como os controladores, os gates também podem ser definidos usando um array de retorno de chamada de classe:

use App\Policies\PostPolicy;
use Illuminate\Support\Facades\Gate;

/**
 * Register any authentication / authorization services.
 */
public function boot(): void
{
    Gate::define('update-post', [PostPolicy::class, 'update']);
}

Autorizando Ações

Para autorizar uma ação usando gates, você deve usar os métodos de permissão ou negação fornecidos pela facade Gate. Observe que você não é obrigado a passar o usuário atualmente autenticado para esses métodos. O Laravel cuidará automaticamente de passar o usuário para o fechamento do gate. É comum chamar os métodos de autorização de gate nos controladores da sua aplicação antes de executar uma ação que exija autorização:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class PostController extends Controller
{
    public function index()
    {
         // Busca todos os posts
        $posts = Post::with('user')->get();

        // Retorna a view com os posts
        return view('posts.index', compact('posts'));
    }

    public function edit(Post $post)
    {
        // Verifica se o usuário pode editar o post
        // allows - permite
        if (Gate::allows('update-post', $post)) {
            return view('posts.edit', compact('post'));
        } else {
            abort(403, 'Você não tem permissão para editar este post.');
        }
    }

    public function update(Request $request, Post $post): RedirectResponse
    {
        // Verifique se o usuário pode atualizar o post
        if (Gate::allows('update-post', $post)) {

            // Valida os dados
            $validated = $request->validate([
                'title' => 'required|string|max:255',
                'content' => 'required|string',
            ]);

            // Atualiza o post
            $post->update($validated);

            return redirect('/posts');

        } else {
            abort(403, 'Você não tem permissão para atualizar este post.');
        }
    }
}

Crie as views necessárias:

/* resources/views/posts/edit.blade.php */
@extends('layouts.app')

@section('content')
<div class="container">
    <h1>Editar Post</h1>

    @if (session('status'))
        <div class="alert alert-success">
            {{ session('status') }}
        </div>
    @endif

    <form action="{{ route('post.update', $post) }}" method="POST">
        @csrf
        @method('PATCH')

        <div class="mb-3">
            <label for="title" class="form-label">Título</label>
            <input type="text" class="form-control" id="title" name="title" value="{{ old('title', $post->title) }}" required>
        </div>

        <div class="mb-3">
            <label for="content" class="form-label">Conteúdo</label>
            <textarea class="form-control" id="content" name="content" rows="5" required>{{ old('content', $post->content) }}</textarea>
        </div>

        <button type="submit" class="btn btn-primary">Atualizar</button>
    </form>
</div>
@endsection

/* resources/views/posts/index.blade.php */
@extends('layouts.app')

@section('content')
<div class="container">
    <h1>Todos os Posts</h1>

    <table class="table">
        <thead>
            <tr>
                <th>Título</th>
                <th>Conteúdo</th>
                <th>Autor</th>
                <th>Ações</th>
            </tr>
        </thead>
        <tbody>
            @foreach ($posts as $post)
                <tr>
                    <td>{{ $post->title }}</td>
                    <td>{{ $post->content }}</td>
                    <td>{{ $post->user->name }}</td>
                    <td>
                        <!-- Botão de edição -->
                        <a href="{{ route('post.edit', $post) }}" class="btn btn-primary">Editar</a>

                        <!-- Formulário de exclusão -->
                        <form action="{{ route('post.delete', $post) }}" method="POST" style="display: inline;" onsubmit="return confirm('Tem certeza que deseja excluir este post?');">
                            @csrf
                            @method('DELETE')
                            <button type="submit" class="btn btn-danger">Deletar</button>
                        </form>
                    </td>
                </tr>
            @endforeach
        </tbody>
    </table>

    @if (Auth::user()->can('view-users'))
        <a href="{{ url('/users') }}">Lista de usuários</a>
    @endif

</div>
@endsection

/* Rotas */
Route::middleware('auth')->group(function () {
    Route::get('/posts', [PostController::class, 'index'])->name('posts.index');
    Route::get('/post/{post}/edit', [PostController::class, 'edit'])->name('post.edit');
    Route::patch('/post/{post}', [PostController::class, 'update'])->name('post.update');
    Route::delete('/posts/{post}', [PostController::class, 'destroy'])->name('post.delete');
});

Veja na imagem abaixo a rota posts!

Veja na imagem abaixo a rota para editar um post especifico!

Autorizando ou lançando exceções

Se você quiser tentar autorizar uma ação e lançar automaticamente uma Illuminate\Auth\Access\AuthorizationException se o usuário não tiver permissão para executar a ação dada, você pode usar o método de autorização da fachada Gate.

Instâncias de AuthorizationException são automaticamente convertidas em uma resposta HTTP 403 pelo manipulador de exceções do Laravel:

Gate::authorize('update-post', $post);

// The action is authorized...

Exemplo, no método destroy:

namespace App\Http\Controllers;

use App\Models\Post;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;

class PostController extends Controller
{

    // outros métodos ...

    public function destroy(Post $post)
    {
        // Verifica se o usuário pode deletar o post
        if (Gate::authorize('delete-post', $post)) {

            // O usuário pode deletar o post
            $post->delete();
            return redirect('/posts');

        } else {
            // O usuário não tem permissão para deletar o post
            abort(403, 'Você não tem permissão para excluir este post.');
        }
    }
}

Resultado. lança automaticamente uma Illuminate\Auth\Access\AuthorizationException:

Interceptando verificações de gate

Às vezes, você pode querer conceder todas as habilidades a um usuário específico. Você pode usar o método before para definir um fechamento que será executado antes de todas as outras verificações de autorização:

use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::before(function (User $user, string $ability) {
    if ($user->isAdministrator()) {
        return true;
    }
});

Se o fechamento anterior retornar um resultado não nulo, esse resultado será considerado o resultado da verificação de autorização.

Vamos criar um exemplo prático para entendermos o uso do Gate::before.

Route::middleware('auth')->group(function () {
    Route::get('/posts', [PostController::class, 'index'])->name('posts.index');
    Route::get('/post/{post}/edit', [PostController::class, 'edit'])->name('post.edit');
    Route::patch('/post/{post}', [PostController::class, 'update'])->name('post.update');
    Route::delete('/posts/{post}', [PostController::class, 'destroy'])->name('post.delete');

    // Crie as rotas abaixo:
    Route::get('/users', [UserController::class, 'index'])->name('users.index');
    Route::post('/users/{user}/toggle-admin', [UserController::class, 'toggleAdmin'])->name('users.toggleAdmin');
});

Crie um controller para o user:

sail artisan make:controller UserController

Código completo do UserController:

<?php

namespace App\Http\Controllers;

use App\Models\User;

class UserController extends Controller
{
    public function index()
    {
        $users = User::all();
        return view('users.index', compact('users'));
    }

    public function toggleAdmin(User $user)
    {
        $user->is_admin = !$user->is_admin;
        $user->save();

        return redirect()->route('users.index')->with('success', 'Status de administrador alterado com sucesso.');
    }
}

Vamos criar uma view para listar os usuários:

// resources/views/users/index.blade.php
@extends('layouts.app')
@section('content')
<div class="container">
    <h1>Lista de Usuários</h1>

    @if (session('success'))
        <div style="color: green;">
            {{ session('success') }}
        </div>
    @endif

    <table border="1">
        <thead>
            <tr>
                <th>ID</th>
                <th>Nome</th>
                <th>Email</th>
                <th>Administrador</th>
                <th>Ações</th>
            </tr>
        </thead>
        <tbody>
            @foreach ($users as $user)
                <tr>
                    <td>{{ $user->id }}</td>
                    <td>{{ $user->name }}</td>
                    <td>{{ $user->email }}</td>
                    <td>{{ $user->is_admin ? 'Sim' : 'Não' }}</td>
                    <td>
                        <form action="{{ route('users.toggleAdmin', $user) }}" method="POST">
                            @csrf
                            <button type="submit">
                                {{ $user->is_admin ? 'Remover Admin' : 'Tornar Admin' }}
                            </button>
                        </form>
                    </td>
                </tr>
            @endforeach
        </tbody>
    </table>

    <a href="{{ url('/posts')  }}">Ver Postagens</a>
</div>
@endsection

Agora na model User, adicione o seguinte código:

public function isAdministrator()
{
  return $this->is_admin; // Assume que 'is_admin' é uma coluna booleana na tabela 'users'
}

Vamos criar uma migration para adicionar a coluna is_admin na tabela users:

sail artisan make:migration add_is_admin_to_users_table --table=users

Schema::table('users', function (Blueprint $table) {
  // Adiciona a coluna is_admin após a coluna email
  $table->boolean('is_admin')->default(false)->after('email');
});

Schema::table('users', function (Blueprint $table) {
  $table->dropColumn('is_admin');
});

Execute o comando abaixo para atualizar a tabela users:

sail artisan migrate

Veja que foi adicionado a coluna is_admin com o valor 0.

Altere para 1 o primeiro usuário:

Agora no front, observe que o usuário autenticado é o areadev e ele pode editar os posts do usuário bruno.

Vamos definir um gate para visualizar a opção "Lista de usuários" quando o user autenticado for admin.

Gate::define('view-users', function (User $user) {
   return $user->is_admin; 
});

Observe que para o usuário que não é admin, não aparece a opção "Lista de usuários" no canto inferior esquerdo da tela.

O método Gate::after permite que você execute uma lógica depois de todas as outras verificações de autorização. Isso é útil para fazer log ou auditoria das decisões de autorização, ou para aplicar regras adicionais depois das verificações normais:

use App\Models\User;
use Illuminate\Support\Facades\Gate;

Gate::after(function (User $user, $ability, $result, $arguments) {
  Log::info('Autorização: ', [
    'user_id' => $user->id,
    'ability' => $ability,
    'result' => $result,
    'arguments' => $arguments,
  ]);
});

Veja o arquivo laravel.log dentro da pasta storage/logs

Semelhante ao método before, se o fechamento posterior retornar um resultado não nulo, esse resultado será considerado o resultado da verificação de autorização.

Introdução

Gerenciar o esquema do banco de dados de maneira controlada e repetível é uma necessidade crucial em qualquer aplicação. No Laravel, isso é facilitado por migrações e seeders.

As migrações permitem criar e modificar tabelas no banco de dados, enquanto os seeders são usados para popular tabelas com dados iniciais ou de teste.

Migrações

O Que São Migrações?

Migrações são como controle de versão para o banco de dados. Elas permitem que você modifique a estrutura do banco de dados de maneira incremental e segura.

Criando uma Migração

Você pode criar uma migração usando o Artisan CLI:

php artisan make:migration create_fruits_table

Isso criará um arquivo de migração em database/migrations. Um arquivo de migração típico tem dois métodos: up e down. O método up é usado para aplicar as alterações no banco de dados, enquanto o método down desfaz essas alterações.

<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateFruitsTable extends Migration
{
    public function up()
    {
        Schema::create('fruits', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('color');    
            $table->timestamps();
        });
    }

    public function down()
    {
        Schema::dropIfExists('fruits');
    }
}

Executando Migrações

Para executar todas as migrações pendentes, use o comando:

sail artisan migrate

Para reverter a última migração, use:

sail artisan migrate:rollback

Modificando Tabelas Existentes

Você pode criar uma migração para modificar uma tabela existente:

sail artisan make:migration add_price_to_fruits_table --table=fruits

No método up, você define as alterações:

<?php
    public function up()
    {
        Schema::table('fruits', function (Blueprint $table) {
            $table->integer('price')->nullable();
        });
    }

    public function down()
    {
        Schema::table('fruits', function (Blueprint $table) {
            $table->dropColumn('price');
        });
    }

Seeders

O Que São Seeders?

Seeders são classes usadas para popular o banco de dados com dados iniciais ou de teste. Eles são úteis para preencher tabelas com dados que você pode usar durante o desenvolvimento ou para testar sua aplicação.

Criando um Seeder

Você pode criar um seeder usando o Artisan CLI:

sail artisan make:seeder FruitsTableSeeder

Isso criará um arquivo de seeder em database/seeders. Você pode definir os dados a serem inseridos no método run:

<?php
use Illuminate\Database\Seeder;
use App\Models\Fruit;

class FruitsTableSeeder extends Seeder
{
    public function run()
    {
        Fruit::create([
            'name' => 'Abacaxi',
            'color' => 'Amarelo',
        ]);

        Fruit::create([
            'name' => 'Banana',
            'color' => 'Amarela',
        ]);
    }
}

Executando Seeders

Para executar todos os seeders, use o comando:

sail artisan db:seed

Lembre-se de adicionar o seeder criado dentro do DatabaseSeeder.php

$this->call(FruitsTableSeeder::class);

Para executar um seeder específico, use:

sail artisan db:seed --class=FruitsTableSeeder

Models

Uma model no Laravel (e em muitos outros frameworks MVC - Model-View-Controller) é uma classe que representa uma entidade da aplicação, geralmente ligada a uma tabela específica no banco de dados. A model serve como a camada intermediária entre a aplicação e o banco de dados, facilitando o gerenciamento de dados.

sail artisan make:model Fruit

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Fruit extends Model
{
    use HasFactory;

    protected $fillable = [
        'name',
        'color',
        'price',
    ];
}

Factories e Seeders

Factories são frequentemente usadas em conjunto com seeders para gerar dados de teste realistas. Primeiro, você cria uma factory:

sail artisan make:factory FruitFactory --model=Fruit

No arquivo da factory, você define como os dados fictícios devem ser gerados:

<?php

namespace Database\Factories;

use App\Models\Fruit;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Str;

class FruitFactory extends Factory
{
    protected $model = Fruit::class;

    public function definition()
    {
        return [
            'name' => $this->faker->word,
            'color' => $this->faker->safeColorName,
            'price' => $this->faker->randomFloat(2, 1000, 5000),
        ];
    }
}

No seeder, você pode usar a factory para criar múltiplos registros:

<?php
use Illuminate\Database\Seeder;
use App\Models\Fruit;

class FruitsTableSeeder extends Seeder
{
    public function run()
    {
        Fruit::factory()->count(10)->create();
    }
}

Conclusão

Migrações e seeders são ferramentas poderosas no Laravel para gerenciar o esquema do banco de dados e popular tabelas de forma controlada e repetível. Elas permitem que você mantenha o banco de dados sincronizado e cheio de dados úteis durante o desenvolvimento e testes. Nos próximos tópicos, exploraremos outras funcionalidades avançadas do Laravel para continuar aprimorando suas habilidades no desenvolvimento de aplicações robustas e eficientes.

Eloquent ORM (Object-Relational Mapping) é o mapeador de objetos-relacionais do Laravel, que facilita a interação com o banco de dados. Com o Eloquent, você pode trabalhar com seus dados de maneira intuitiva e orientada a objetos, sem precisar escrever consultas SQL complexas.

Definição de Modelos

Os modelos no Eloquent representam as tabelas do banco de dados. Cada modelo é responsável por interagir com uma tabela específica e suas respectivas colunas.

Criando um Modelo

Você pode criar um modelo usando o Artisan CLI:

php artisan make:model NomeDoModelo

Isso criará um arquivo de modelo em app/Models/NomeDoModelo.php. Um modelo básico pode parecer assim:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class NomeDoModelo extends Model
{
    use HasFactory;
}

Por padrão, o modelo assume que a tabela associada tem o nome pluralizado em inglês do nome do modelo (por exemplo, um modelo User se relaciona à tabela users). Você pode especificar explicitamente a tabela usando a propriedade $table:

<?php
class NomeDoModelo extends Model
{
    protected $table = 'nome_da_tabela';
}

Trabalhando com Modelos

Com um modelo definido, você pode realizar várias operações de banco de dados. Aqui estão alguns exemplos:

• Recuperando todos os registros:

    <?php $users = User::all();
  

• Encontrando um registro por ID:

    <?php $user = User::find(1);
  

• Criando um novo registro:

    <?php 
        $user = new User;
        $user->name = 'John Doe';
        $user->email = 'john@example.com';
        $user->save();
  

• Atualizando um registro existente:

    <?php 
        $user = User::find(1);
        $user->name = 'Jane Doe';
        $user->save();
  

• Excluindo um registro:

    <?php
        $user = User::find(1);
        $user->delete();
  

Relacionamentos

O Eloquent facilita a definição e o trabalho com relacionamentos entre modelos. Existem vários tipos de relacionamentos, incluindo one-to-one, one-to-many e many-to-many.

One-to-One

Um relacionamento one-to-one ocorre quando uma linha em uma tabela está associada a exatamente uma linha em outra tabela.

• Definindo um relacionamento one-to-one:

    <?php
        class User extends Model
        {
            public function phone()
            {
                return $this->hasOne(Phone::class);
            }
        }
  
        class Phone extends Model
        {
            public function user()
            {
                return $this->belongsTo(User::class);
            }
        }
  

• Usando um relacionamento one-to-one:

    <?php
        $user = User::find(1);
        $phone = $user->phone;
  

One-to-Many

Um relacionamento one-to-many ocorre quando uma linha em uma tabela pode estar associada a várias linhas em outra tabela.

• Definindo um relacionamento one-to-many:

    <?php
        class Post extends Model
        {
            public function comments()
            {
                return $this->hasMany(Comment::class);
            }
        }
  
        class Comment extends Model
        {
            public function post()
            {
                return $this->belongsTo(Post::class);
            }
        }
  

• Usando um relacionamento one-to-many:

    <?php
        $post = Post::find(1);
        $comments = $post->comments;
  

Many-to-Many

Um relacionamento many-to-many ocorre quando várias linhas em uma tabela estão associadas a várias linhas em outra tabela. Esse tipo de relacionamento usa uma tabela intermediária.

• Definindo um relacionamento many-to-many:

    <?php
        class User extends Model
        {
            public function roles()
            {
                return $this->belongsToMany(Role::class);
            }
        }
  
        class Role extends Model
        {
            public function users()
            {
                return $this->belongsToMany(User::class);
            }
        }
  

• Usando um relacionamento many-to-many:

    <?php
        $user = User::find(1);
        $roles = $user->roles;
  

• Sincronizando relacionamentos many-to-many:

    <?php
        $user = User::find(1);
        $user->roles()->sync([1, 2, 3]);
  

Conclusão

O Eloquent ORM é uma ferramenta poderosa que facilita a interação com o banco de dados de forma intuitiva e eficiente. Com a definição de modelos e relacionamentos, você pode manipular os dados da sua aplicação de maneira estruturada e orientada a objetos. Nos próximos tópicos, exploraremos mais funcionalidades avançadas do Laravel, incluindo migrations, seeders e factories, para facilitar o desenvolvimento e a gestão do banco de dados.