DEV Community: Quasar Framework Brasil

Protegendo uma aplicação com Refresh Tokens.

Tobias Mesquita — Tue, 07 Mar 2023 19:03:11 +0000

Índice

Source - Backend
1 - Backend - Conhecendo o Backend
2 - Backend - Endpoint de Login
- 2.1 - Parâmetros do Login
- 2.2 - Analisando o Login
  - 2.2.1 - Primeiro Cenário - flow=server e rotation=false
  - 2.2.2 - Segundo Cenário - flow=client e rotation=true
3 - Backend - Endpoint de Refresh
- 3.1 - Parâmetros do Refresh
- 3.2 - Analisando o Refresh
  - 3.2.1 - Primeiro Cenário - flow=server e rotation=false
  - 3.2.2 - Segundo Cenário - flow=client e rotation=true
4 - Backend - Endpoint de Logout
5 - Frontend - Entendendo as Vulnerabilidades
6 - Frontend - Protegendo um App SPA
- 6.1 - Realizando o Refresh
- 6.2 - Integrando a uma API com flow=server
- 6.3 - Integrando a uma API com rotation=true
7 - Frontend - Protegendo um App SSR
- 7.1 - Integrando a uma API com rotation=true
- 7.2 - Integrando a uma API com rotation=false
  - 7.2.1 - Preparando o Server Side
  - 7.2.2 - Comunicação entre o Server Side e o Client Side

1 - Backend - Conhecendo o Backend

Voltar ao Topo

Antes de começamos a proteger a nossa aplicação, precisamos conhecer o Backend com o qual iremos conectar, assim como descobrir quais escolhas o mesmo adotou, uma vez que existe diferentes formas de criar e gerenciar os refresh tokens.

Para este artigo, estarei usando como base uma API feita com NestJS que usa um esquema de Refresh definido por mim, porém que cobre a maioria dos modelos e/ou estrategias de refresh token existentes.

O código fonte da API por ser encontrado no seguinte repositorio.:
https://github.com/TobyMosque/ws-auth-samples-backend/tree/refresh-after-spa

porém, não se preocupe com o código em si, mas com o comportamento da API, primeiro devemos analisar todos os endpoints utilizados para a autenticação.

2 - Backend - Endpoint de Login

Voltar ao Topo

O primeiro endpoint que iremos visitar é o de login:

2.1 - Parâmetros do Login

Voltar ao Topo

Note que além do body com o username e o password, temos dois parâmetros que são passados na query string, estes parâmetros são utilizados para instruir o backend de como iremos gerenciar o refresh token.

rotation: valor boleano (true/false) que define se iremos usar rotação de tokens ou não

true: o refresh_token poderá ser usado apenas uma vez, então a cada /refresh a API irá retornar um novo refresh_token além de um access_token renovado.
false: o refresh_token poderá ser utilizado multiplas vezes.

flow: enumerador que define quem irá gerenciar o refresh_token

server: a API não irá devolver o refresh_token ao cliente, ficando a API responsável pela segurança do refresh_token, nesta caso o refresh_token é persistido em um cookie seguro.
client: a API irá devolver o refresh_token ao cliente, neste caso a API não irá persistir e/ou gerenciar o refresh_token, ficando a cargo do cliente a segurança do mesmo.

2.2 - Analisando o Login

Voltar ao Topo

Agora vamos fazer algumas chamadas a API para que possamos observar os diferentes comportamentos.

2.2.1 - Primeiro Cenário - flow=server e rotation=false

Voltar ao Topo

Veja, que a API retornou a seguinte resposta:

{
  "accessToken": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTgwY2E2My0yYjUyLTRlYjAtOTJlNi1mMWNlMzYxM2IxNjYiLCJuYW1lIjoiVG9iaWFzIE1lc3F1aXRhIiwiZW1haWwiOiJtZUB0b2JpYXNtZXNxdWl0YS5kZXYiLCJyb2xlcyI6WyJkZXZlbG9wZXIiLCJhZG1pbiIsInVzZXIiXSwiaWF0IjoxNjc4MDQ4NjQ0LCJleHAiOjE2NzgwNDg2NzQsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiODBmMDQxMDctMGE4MS00ZWNhLWE1ODItNWM3NzViNDQ4MWJmIn0.GIAeo5sfrA5ksKp5msAJCAxLo4ivHxoHrTz6j9JBWyVgg3BmHN0veF24V27PG_K8yqjMiCKRONuNwkdZHENdQg"
}

então, podemos fazer o decode do token em https://jwt.io

[{
  "alg": "HS512",
  "typ": "JWT"
}, {
  "sub": "0180ca63-2b52-4eb0-92e6-f1ce3613b166",
  "name": "Tobias Mesquita",
  "email": "me@tobiasmesquita.dev",
  "roles": [
    "developer",
    "admin",
    "user"
  ],
  "iat": 1678048644,
  "exp": 1678048674,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "80f04107-0a81-4eca-a582-5c775b4481bf"
}]

Se analisamos o iat e o exp, veremos que o token tem validade de 30 segundos, ou seja, se trata de um token de curta duração:

{
  iat: '05/03/2023 17:37:24'
  exp: '05/03/2023 17:37:54'
}

Também podemos verificar que a API não retornou o refresh_token, porém o salvou como um cookie.

Set-Cookie: 
  REFRESH_TOKEN=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2NzgwNDg2NDQsImV4cCI6MTY3ODEzNTA0NCwiYXVkIjoiaHR0cHM6Ly9qd3Qtc2FtcGxlLnRvYmlhc21lc3F1aXRhLmRldiIsImlzcyI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJqdGkiOiI4MGYwNDEwNy0wYTgxLTRlY2EtYTU4Mi01Yzc3NWI0NDgxYmYifQ.GW3o37wLXY6eg4_ns9xuDKb8UOwlw1SF2CHdtWaXdXg;
  Path=api/auth/refresh; 
  Expires=Mon, 06 Mar 2023 20:37:24 GMT; 
  HttpOnly; 
  Secure; 
  SameSite=Lax

E no caso desta API, o refresh_token também é token assinado, assim como o access_token, então também podemos fazer o decode do mesmo em https://jwt.io.

[{
  "alg": "HS256",
  "typ": "JWT"
}, {
  "iat": 1678048644,
  "exp": 1678135044,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "80f04107-0a81-4eca-a582-5c775b4481bf"
}]

E novamente poderemos analisar as datas de criação e expiração, e veremos que se trata de um token de longa duração, com validade de 24 horas:

{
  iat: '05/03/2023 17:37:24'
  exp: '06/03/2023 17:37:24'
}

2.2.2 - Segundo Cenario - flow=client e rotation=true

Voltar ao Topo

Veja, que a API retornou a seguinte resposta:

{
  "accessToken": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIwMTgwY2E2My0yYjUyLTRlYjAtOTJlNi1mMWNlMzYxM2IxNjYiLCJuYW1lIjoiVG9iaWFzIE1lc3F1aXRhIiwiZW1haWwiOiJtZUB0b2JpYXNtZXNxdWl0YS5kZXYiLCJyb2xlcyI6WyJkZXZlbG9wZXIiLCJhZG1pbiIsInVzZXIiXSwiaWF0IjoxNjc4MDQ5MDcwLCJleHAiOjE2NzgwNDkxMDAsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiMTViYzJlMjctMjkxYy00MzE5LTgxNWYtYTc1NDJkNWZmZTAyIn0.Xz--Ep6eTUGl_YG6VejwJFqaR-WKCPzFDywvT57KnU9eZ3lj9Con6GDZK5EEjFDTdBNvcfc3xsI5xtnuITLIOg",
  "refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZWZyZXNoIjoiZjQzZmE0MDMtNTE3Yi00YmEzLTljNTktNDRjYzAxZGMzOWVjIiwiaWF0IjoxNjc4MDQ5MDcwLCJleHAiOjE2NzgxMzU0NzAsImF1ZCI6Imh0dHBzOi8vand0LXNhbXBsZS50b2JpYXNtZXNxdWl0YS5kZXYiLCJpc3MiOiJodHRwczovL2p3dC1zYW1wbGUudG9iaWFzbWVzcXVpdGEuZGV2IiwianRpIjoiMTViYzJlMjctMjkxYy00MzE5LTgxNWYtYTc1NDJkNWZmZTAyIn0.WtFmPuhQMrDvxkxoyc6rAFtr4wXErnMhnqRa4_VZ6Ts"
}

Desta vez, a API retornou o refresh_token como parte da resposta (body) e não como um cookie, ficando a critério da API decidir qual é a melhor estratégia para proteger o refresh_token.

Como o access_token, terá o mesmo formato independente do flow e do rotation que forem passados, não é necessário decompor ele novamente, porém o refresh_token terá uma claim a mais.

[{
  "alg": "HS256",
  "typ": "JWT"
}, {
  "refresh": "f43fa403-517b-4ba3-9c59-44cc01dc39ec",
  "iat": 1678049070,
  "exp": 1678135470,
  "aud": "https://jwt-sample.tobiasmesquita.dev",
  "iss": "https://jwt-sample.tobiasmesquita.dev",
  "jti": "15bc2e27-291c-4319-815f-a7542d5ffe02"
}]

A API irá utilizar a claim refresh para identificar que o refresh_token só pode ser utilizado uma vez, e se o mesmo já foi utilizado.

3 - Backend - Endpoint de Refresh

Voltar ao Topo

Agora que o login já foi bem dissecado, porém voltar a nossa atenção para o refresh

3.1 - Parâmetros do Refresh

Voltar ao Topo

Assim como no login, temos que passar alguns argumentos na query string, porém devemos passar apenas o flow, que deve ser igual ao que passamos durante o login.

flow: enumerador que define como o refresh_token será passado para a API.

server: a API escreveu um cookie, então a API deve ler deste cookie.
client: a aplicação Cliente deve passar o refresh_token no header RefreshToken.

3.2 - Analisando o Refresh

Voltar ao Topo

Agora, vamos dá continuidade aos cenários apresentados no login.

3.2.1 - Primeiro Cenário - flow=server e rotation=false

Voltar ao Topo

Neste caso, o refresh_token será lido do cookie, como não instruímos a API para utilizar o rotation do refresh_token, um novo refresh_token não foi gerado, e o cookie não será sobescrito.

3.2.2 - Segundo Cenário - flow=server e rotation=false

Voltar ao Topo

Neste exemplo, como o refresh_token foi criado usando o flow=client e o rotation=false, ele precisou ser enviado no header, assim como ele foi invalidado e um novo refresh_token, este estando disponível da resposta (body) da requisição feita à API.

4 - Backend - Endpoint de Logout

Voltar ao Topo

E por fim temos o endpoint /logout:

Neste caso só há uma coisa a ser dita, caso o flow=server, estamos instruindo a API a apagar o cookie gerenciado pela API.

5 - Frontend - Entendendo as Vulnerabilidades

Voltar ao Topo

Quando falamos em proteger uma aplicação, temos de pensar nas principais vulnerabilidades que podem ocorrer ao se optar por utilizar tokens JWT para realizar a Autenticação e/ou Autorização.

Neste ponto, as duas principais vulnerabilidades são a XSS (Cross-Site Scripting) ou a CSRF (Cross-Site Request Forgery).

XSS: O ataque se dá pela injeção de um script que será capaz de ler o LocalStorage, SessionStorage, Cookies não seguros, ou qual quer outra informação que esteja disponível globalmente. Evitamos este problema ao não disponibilizar dados sensiveis globalmente.
CSRF: O cookie com o Token JWT é enviado para outro servidor, podendo assim ser lido por uma aplicação maliciosa. Evitamos este problema ao marcar o nosso cookie com HttpOnly; Secure; SameSite=Lax.

6 - Frontend - Protegendo um App SPA

Voltar ao Topo

Agora vamos falar sobre como proteger uma Aplicação SPA, porém isto também se aplica à aplicações PWA, Cordova, Capacitor e Electron. Ou seja, aplicações cujo o build possui apenas arquivos estáticos, não contando com a possibilidade de possuir um servidor/backend proprio.

Neste caso, para mantemos a aplicação segura, teremos de contar com uma API/Backend que disponibilize o flow=server ou o rotation=true.

6.1 - Realizando o Refresh

Voltar ao Topo

Mas vale ressaltar que independente do fluxo que iremos adotar, o boot do axios irá ser o mesmo, sendo que todos os ajustes serão feitos apenas no composable responsável pela autenticação.

No boot do Axios/API iremos injetar o Access Token no header e realizar o refresh caso o Access Token expire.

src/boot/axios.ts

import { boot } from 'quasar/wrappers';
import axios from 'axios';
import { InjectionKey } from 'vue';
import { useAuth } from 'src/composables/auth';

export const apiKey: InjectionKey<AxiosInstance> = Symbol('api-key');

export default boot(async ({ app, store, router }) => {
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const { token, refresh } = useAuth(api);

  api.interceptors.request.use(
    function (config) {
      if (token.value) {
        config.headers ||= {}
        config.headers.Authorization = `Bearer ${token.value}`;
      }
      return config;
    },
    function (error) {
      return Promise.reject(error);
    }
  );

  api.interceptors.response.use(
    function (response) {
      return response;
    },
    async function (error) {
      const res = error.response;
      switch (res.status) {
        case 401:
          if (token.value) {
            await refresh()
            if (token.value) {
              return api.request(error.config);
            }
          }
          break;
      }
      return Promise.reject(error);
    }
  );
  await refresh();
})

Agora algumas explicações, como podemos ver nos destaques na imagem abaixo, o token é injetado no request, e caso haja um erro do tipo 401 no response, o refresh é acionado e a requisição é refeita.

6.2 - Integrando a uma API com flow=server

Voltar ao Topo

Ao optamos por confiamos a segurança do Access Token à API, e caso a API persista o Refresh Token em um Cookie Seguro, a aplicação estará completamente imune a ataques do tipo XSS e/ou CSRF.

Agora irei mostrar um exemplo de implementação com o flow=server

src/composables/auth.ts

import { ref, computed } from 'vue'
import jwtDecode from 'jwt-decode';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
function useAuth (api: AxiosInstance) {
  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })

  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=server');
    token.value = data.accessToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=server');
      token.value = data.accessToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=server');
    token.value = '';
  }


  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}

Note que no código acima estamos armazenando o token em memoria, assim como disponibilizamos os métodos de login, refresh e logout. Vale salientar que refresh_token não é accessível pelo frontend.

6.3 - Integrando a uma API com rotation=true

Voltar ao Topo

No caso da API não se responsabilizar pelo Refresh Token, ou de termos algo que esteja a bloquear o Cookie Seguro da API, teremos de persistir o Refresh Token no Local Storage, o que irá abrir a nossa aplicação à um ataque do tipo XSS.

Para mitigamos este problema, devemos adotar o rotation=true, de forma que o token será invalidado a cada uso, ou seja, em 99% dos casos, o Refresh Token será invalidado junto ao Access Token, o que limita o Ataque do tipo XSS e qual quer dano que venha a ser gerado por ele.

Agora iremos abordar o fluxo com flow=client com rotation=true
src/composables/auth.ts

import { ref, computed } from 'vue'
import { useLocalStorage } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
const refresh = useLocalStorage('refresh-token', '')
function useAuth (api: AxiosInstance) {
  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=client&rotation=true');
    token.value = data.accessToken;
    refresh.value = data.refreshToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=client', {
        headers: {
          RefreshToken: refresh.value
        }
      });
      token.value = data.accessToken;
      refresh.value = data.refreshToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
        refresh.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=client');
    token.value = '';
    refresh.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}

Neste caso, o refresh token é gerenciado pelo frontend, e por isto podemos ver que o mesmo é lido, escrito e persistido.

7 - Frontend - Protegendo um App SSR

Voltar ao Topo

Agora que concluímos as explicações sobre aplicações SPA, vamos falar sobre SSR, e neste caso o refresh_token deve ser compartilhado entre o server-side e o client-side, e por isto não podemos usar o flow=server e seremos forçados a armazenar o Refresh Token em um Cookie gerenciado pelo nosso Frontend.

De toda forma, temos duas opções, uma usando rotation=true, onde o armazenando no refresh_token será no client-side. Caso tenhamos que usar o rotation=false, teremos que armazenar no server-side e usar um ssrMiddleware para criar uma API intermediária entre o server-side e o client-side.

7.1 - Integrando a uma API com rotation=true

Voltar ao Topo

No caso do rotation=true a implementação é a mesma que usamos no SPA mode, mas iremos usar um CookieStorage ao invés do LocalStorage.

src/composables/auth.ts

import { ref, computed, Ref } from 'vue'
import { useStorage, StorageLike } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import { Cookies } from 'quasar';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('')
let refresh: Ref<string>;
function useAuth (api: AxiosInstance, cookies: Cookies) {
  if (!refresh) {
    const opts = { path: '/', sameSite: 'Lax', secure: true }
    const storage: StorageLike = {
      getItem(key: string) {
        return JSON.stringify(cookies.get(key));
      },
      setItem(key: string, value: string) {
        const obj = JSON.parse(value);
        cookies.set(key, obj, opts);
      },
      removeItem: function (key: string): void {
        cookies.remove(key, opts);
      }
    }
    refresh = useStorage('refresh-token', '', storage)
  }

  async function login (req: LoginRequest) {
    const { data } = await api.post('/auth/login?flow=client&rotation=true');
    token.value = data.accessToken;
    refresh.value = data.refreshToken;
  }
  async function refresh (req: LoginRequest) {
    try {
      const { data } = await api.get('/auth/refresh?flow=client', {
        headers: {
          RefreshToken: refresh.value
        }
      });
      token.value = data.accessToken;
      refresh.value = data.refreshToken;
    } catch (error) {
      const res = error.response;
      if (res.status === 401) {
        token.value = '';
        refresh.value = '';
      }
    }
  }
  async function logout (req: LoginRequest) {
    await api.delete('/auth/logout?flow=client');
    token.value = '';
    refresh.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}

E na imagem abaixo, esta em destaque as alterações no composable:

E claro, como o composable agora está esperando os Cookies como argumento, nós precisamos fazer uma modificação no boot.

src/boot/axios.ts

import { boot } from 'quasar/wrappers';
import axios from 'axios';
import { InjectionKey } from 'vue';
import { useAuth } from 'src/composables/auth';
import { Cookies } from 'quasar';

export const apiKey: InjectionKey<AxiosInstance> = Symbol('api-key');
export default boot(async ({ app, store, router, ssrContext }) => {
  const cookies = process.env.SERVER 
    ? Cookies.parseSSR(ssrContext) 
    : Cookies;
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const { token, refresh } = useAuth(api, cookies);

  api.interceptors.request.use(
    function (config) {
      if (token.value) {
        config.headers ||= {}
        config.headers.Authorization = `Bearer ${token.value}`;
      }
      return config;
    },
    function (error) {
      return Promise.reject(error);
    }
  );

  api.interceptors.response.use(
    function (response) {
      return response;
    },
    async function (error) {
      const res = error.response;
      switch (res.status) {
        case 401:
          if (token.value) {
            await refresh()
            if (token.value) {
              return api.request(error.config);
            }
          }
          break;
      }
      return Promise.reject(error);
    }
  );
  await refresh();
})

E mais uma vez, estou colocando em destaque as alterações relevantes.

7.2 - Integrando a uma API com rotation=false

Voltar ao Topo

Agora iremos falar sobre como utilizar o rotation=false com o modo SSR.

7.2.1 - Preparando o Server Side

Voltar ao Topo

No Server Side, teremos de extender a instancia do webserver que serve a aplicação SSR com uma mini API, podemos utilizar um SSRMiddleware para esta tarefa.:

quasar new ssrmiddleware auth

Então iremos adicionar os endpoints /login, /refresh, /logout no nosso middleware

src/utils/index.ts

export const cookieName = 'REFRESH_TOKEN';
export function cookieOptions() {
  const expires = new Date();
  expires.setDate(expires.getDate() + 1);
  return {
    path: ['api', 'auth', 'refresh'].join('/'),
    secure: true,
    sameSite: 'lax',
    httpOnly: true,
    expires: expires,
  };
}

src-ssr/middlewares/auth.ts

import { ssrMiddleware } from 'quasar/wrappers'
import { Router } from 'express';
import axios from 'axios';
import { cookieName, cookieOptions } from '../src/utils';

export default ssrMiddleware(async ({ app /*, resolveUrlPath, publicPath, render */ }) => {
  const url = process.env.API_URL;
  const api = axios.create({ baseURL: url });

  const router = Router()
  router.post('login', async function (req, res) {
    const { data } = await api.post('/auth/login?flow=client&rotation=false');
    res.cookie(cookieName, data.refreshToken, cookieOptions());
    res.json({
      accessToken: data.accessToken
    });
  })
  router.get('refresh', async function (req, res) {
    let accessToken = ''
    const refresh = req.cookies[cookieName];
    if (refresh) {
      const { data } = await api.get('/auth/refresh?flow=client');
      accessToken = data.value;
    }
    return {
      accessToken
    }
  })
  router.delete('logout', async function (req, res) {
    await api.get('/auth/logout?flow=client');
    res.clearCookie(cookieName)
  })
  app.use('/api/auth', router)
})

Note que estamos usando o flow=client no nosso backend, mas na API interna do frontend estamos escrevendo um cookie, e este cookie estará disponível apenas no nosso server-side.

7.2.2 - Comunicação entre o Server Side e o Client Side

Voltar ao Topo

Agora vamos ao nosso composable, ele vai permanecer praticamente o mesmo, mas quando estivemos no client-side, ao invés de chamar a API externa, ele irá chamar a API interna.

src/composables/auth.ts

import { ref, computed, Ref } from 'vue'
import { useStorage, StorageLike } from '@vueuse/core'
import jwtDecode from 'jwt-decode';
import { Cookies } from 'quasar';
import axios from 'axios';
import type { AxiosInstance } from 'axios'
import type { JwtPayload } from 'jwt-decode';
import { cookieName, cookieOptions } from 'src/utils';

type Payload = JwtPayload & { roles: string[] }
interface LoginRequest {
  username: string;
  password: string;
}

const token = ref('');
const internal = axios.create({ baseURL: '/api/auth/' });
function useAuth (api: AxiosInstance, cookies: Cookies) {
  async function login (req: LoginRequest) {
    const { data } = await internal.post('login');
    token.value = data.accessToken;
  }
  async function refresh (req: LoginRequest) {
    if (process.env.CLIENT) {
      const { data } = await internal.get('refresh');
      token.value = data.accessToken;
    }
    if (process.env.SERVER) {
      var refreshToken = cookies.get('REFRESH_TOKEN')
      try {
        const { data } = await api.get('/auth/refresh?flow=client', {
          headers: {
            RefreshToken: refreshToken
          }
        });
        token.value = data.accessToken;
        cookies.set(cookieName, data.refreshToken, cookieOptions());
      } catch (error) {
        const res = error.response;
        if (res.status === 401) {
          token.value = '';
          cookies.remove(cookieName, cookieOptions());
        }
      }
    }
  }
  async function logout (req: LoginRequest) {
    await internal.delete('logout');
    token.value = '';
  }

  const payload = computed(() => {
    if (!token.value) {
      return null;
    }
    return jwtDecode(token.value) as Payload;
  })
  return {
    token,
    payload,
    login,
    refresh,
    logout
  }
}

E por fim os pontos de interrese:

Note que estamos sempre a chamar a API interna, com exceção do refresh, que caso seja executado do server-side irá chamar a API externa diretamente e atualizar o Cookie.

Monorepo - Quasar V2 + NestJS

Tobias Mesquita — Tue, 13 Apr 2021 15:09:07 +0000

1 - Introdução

Este artigo tem como objetivo introduzir um novo recurso do Quasar V2, Middlewares para SSR, este recurso nos permite extender/configurar a instancia do ExpressJS de forma modular, assim como já fazíamos com os boots.

Como caso de uso, iremos criar um Yarn Monorepo, onde o frontend vai aproveitar todo o poder do Quasar CLI, e o backend irá aproveitar tudo o que o seu respectivo cliente tenha a oferecer e a ponte entre ambos será um SSR Middleware.

Desta forma, o frontend e o backend irão ser executados no mesmo Nó (Node), porém é importante que o backend não tenha nenhuma dependência adicional para com o frontend, se mantendo completamente desacoplado, desta forma, a qual quer momento poderemos alternar entre ser executado no seu próprio Nó (Node) ou como um simbionte do frontend.

Para este laboratório, estaremos usando o NestJS, mas pode ser usado qual quer framework que possa ser montado sobre o ExpressJS, como por exemplo o FeathersJS.

2 - Yarn Monorepo

Para esta etapa, precisamos certificar que o NodeJS esteja instalado, de preferencia a versão LTS, caso esteja usando a versão Current, pode ser que enfrente problemas inesperados, seja agora ou no futuro.

Caso não o tenha, recomendo que instale através do NVM, segue os links para o NVM Linux/Mac e para o NVM Windows.

Claro, não deixe de instalar todos os command cli que iremos está utilizando:

npm i -g yarn@latest
npm i -g @quasar/cli@latest
npm i -g @nestjs/cli@latest
npm i -g concurrently@latest

E agora crie os seguintes arquivos na raiz do projeto:

./package.json

{
  "private": true,
  "workspaces": {
    "packages": ["backend", "frontend"]
  },
  "scripts": {}
}

./.gitignore

.DS_Store
.thumbs.db
node_modules

# Log files
npm-debug.log*
yarn-debug.log*
yarn-error.log*

# Editor directories and files
.idea
*.suo
*.ntvs*
*.njsproj
*.sln

./.gitmodules

[submodule "backend"]
path = backend
url = git@github.com:${YOUR_USER}/${YOUR_BACKEND_REPO}.git

[submodule "frontend"]
path = frontend
url = git@github.com:${YOUR_USER}/${YOUR_FRONTEND_REPO}.git

Não deixe de modificar o YOUR_USER, YOUR_BACKEND_REPO e o YOUR_FRONTEND_REPO para apontarem para o seu próprio repositório, isto claro, se pretende visionar este projeto.

3 - Backend Project - NestJS

Agora iremos criar o projeto do backend, para tal execute:

nest new backend

Segue as opções selecionadas:

? Which package manager would you ❤️ to use? yarn

Note que temos dois node_modules, um na raiz do monorepo e outro no projeto backend, no node_modules do monorepo é onde é instalado a maioria das nossas dependências.

por fim, adicione alguns scripts ao ./package.json na raiz do monorepo:

{
  "private": true,
  "workspaces": {
     "packages": ["backend", "frontend"]
  },
  "scripts": {
    "backend:dev": "yarn workspace backend build:dev",
    "backend:build": "yarn workspace backend build",
    "backend:start": "yarn workspace backend start",
    "postinstall": "yarn backend:build"
  }
}

Então execute:

yarn backend:start

E acesse http://localhost:3000

4 - Backend Project - OpenAPI

A razão pela qual escolhi o NestJS para este laboratorio, é pela possibilidade de auto documentar a API com pouco ou nenhum esforço adicional. Porém pode usar qualquer outro Framework, o procedimento e os desafios devem ser bem semelhantes.

Caso prefira GraphQL à REST, você pode ignorar esta etapa, e então instalar os pacotes do NestJS para GraphQL.

Mas para tal, precisamos adicionar alguns pacotes:

yarn workspace backend add @nestjs/swagger swagger-ui-express
yarn workspace backend add --dev @types/terser-webpack-plugin

Então modifique o arquivo main.ts em src/backend
./backend/src/main.ts

import { NestFactory } from '@nestjs/core';
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.setGlobalPrefix('api');
  const config = new DocumentBuilder()
    .setTitle('Quasar Nest example')
    .setDescription('The cats API description')
    .setVersion('1.0')
    .addTag('cats')
    .build();
  const document = SwaggerModule.createDocument(app, config);
  SwaggerModule.setup('api/docs', app, document);
  await app.listen(3000);
}
bootstrap();

Por fim, execute o comando yarn backend:start e acesse http://localhost:3000/api/docs:

5 - Preparar o Backend para integra-lo ao Frontend

Para esta etapa, iremos precisar criar um script no backend com uma assinatura semelhante ao do SSR Middleware que iremos criar no frontend e iremos mover boa parte da logica presente no main.ts para este novo script.

./backend/src/index.ts

import { Express, Request, Response } from 'express';
import { NestFactory } from '@nestjs/core';
import { ExpressAdapter } from '@nestjs/platform-express';
import { DocumentBuilder, SwaggerModule } from '@nestjs/swagger';
import { AppModule } from './app.module';

interface RenderParams {
  req: Request;
  res: Response;
}

interface ConfigureParams {
  app: Express;
  prefix: string;
  render?: (params: RenderParams) => Promise<void>;
}

export default async function bootstrap({
  app: server,
  prefix,
  render,
}: ConfigureParams) {
  const app = await NestFactory.create(AppModule, new ExpressAdapter(server));
  app.setGlobalPrefix(prefix);
  app.useGlobalFilters({
    async catch(exception, host) {
      const ctx = host.switchToHttp();
      const status = exception.getStatus() as number;
      const next = ctx.getNext();
      if (status === 404 && render) {
        const req = ctx.getRequest<Request>();
        const res = ctx.getResponse<Response>();
        await render({ req, res });
      } else {
        next();
      }
    },
  });
  const config = new DocumentBuilder()
    .setTitle('Quasar Nest example')
    .setDescription('The cats API description')
    .setVersion('1.0')
    .addTag('cats')
    .build();
  const document = SwaggerModule.createDocument(app, config);
  SwaggerModule.setup(`${prefix}/docs`, app, document);
  return app;
}

E claro, modifique o main.ts:
./backend/src/index.ts

import configure from './index';
import * as express from 'express';

async function bootstrap() {
  const app = express();
  const nest = await configure({ app, prefix: 'api' });
  await nest.listen(3000);
}
bootstrap();

Feito isto, acesse novamente http://localhost:3030/api/docs e veja se está tudo em ordem.

Então, precisamos alterar o package.json em backend, adicionando um script em scripts.

{
  "main": "dist/index.js",
  "scripts": {
    "build:dev": "nest build --watch"
  }
}

Caso esteja a utilizar o Quasar V1, então temos uma incopatibilidade de versões entre o Webpack usado pelo Quasar e o do NestJS, neste caso precisamos configurar o nohoist no package.json > workspaces:

{
  "main": "dist/index.js",
  "scripts": {
    "build:dev": "nest build --watch"
  },
  "workspaces": {
    "nohoist": [
      "*webpack*",
      "*webpack*/**"
    ]
  }
}

Nós precisamos deste script, pois a configuração do Typescript no frontend é diferente do backend, então o Quasar CLI não será capaz de transpilar do backend, desta forma o frontend irá fazer uso de um arquivo já transpilado (dist/index.js)

precisamos adicionar esta configuração de nohoist ao backend, pois as versões do webpack e dos plugins utilizados pelo Quasar CLI podem ser diferentes das utilizadas pelo NestJS CLI.

por fim, caso revisite o arquivo ./package.json, verá que tem um script de postinstall, ele é necessário para garantir que será feito um build do backend antes de tentar executar o frontend.

6 - Projeto do Frontend - Quasar

Assim como fizemos com o backend, precisamos criar um projeto, para tal, iremos utilizar o quasar cli:

# note que durante a elaboração deste artigo, o Quasar V2 ainda estava em beta, por isto se faz necessário o `-b next`
quasar create frontend -b next

Segue as opções selecionadas:

? Project name (internal usage for dev) frontend
? Project product name (must start with letter if building mobile apps) Quasar App
? Project description A Quasar Framework app
? Author Tobias Mesquita <tobias.mesquita@gmail.com>
? Pick your CSS preprocessor: Sass
? Check the features needed for your project: ESLint (recommended), TypeScript
? Pick a component style: Composition
? Pick an ESLint preset: Prettier
? Continue to install project dependencies after the project has been created? (recommended) yarn

As únicas recomendações que faço aqui, é que use o Yarn e o Prettier

Então, adicione o modo ssr, e o backend como depedencia do frontend:

cd frontend
quasar mode add ssr
cd ..
yarn workspace frontend add --dev @types/compression
yarn workspace frontend add backend@0.0.1

Caso os middlewares sejam criados como .js, você pode transforma-los em arquivos .ts (no momento em que este artigo foi escrito, não havia os templates para Typescript).:

./frontend/src-ssr/middlewares/compression.ts

import compression from 'compression'
import { ssrMiddleware } from 'quasar/wrappers'

export default ssrMiddleware(({ app }) => {
  app.use(
    compression({ threshold: 0 })
  )
})

Por fim, altere o render.js para render.ts e faça que ele se conecte ao backend.

./frontend/src-ssr/middlewares/render.ts

import configure from 'backend'
import { ssrMiddleware } from 'quasar/wrappers'
import { RenderError } from '@quasar/app'

export default ssrMiddleware(async ({ app, render, serve }) => {
  const nest = await configure({
    app,
    prefix: 'api',
    async render ({ req, res }) {
      res.setHeader('Content-Type', 'text/html')

      try {
        const html = await render({ req, res })
        res.send(html)
      } catch (error) {
        const err = error as RenderError
        if (err.url) {
          if (err.code) {
            res.redirect(err.code, err.url)
          } else {
            res.redirect(err.url)
          }
        } else if (err.code === 404) {
          res.status(404).send('404 | Page Not Found')
        } else if (process.env.DEV) {
          serve.error({ err, req, res })
        } else {
          res.status(500).send('500 | Internal Server Error')
        }
      }
    }
  });
  await nest.init()
});

Por fim, modifique o package.json > scripts do frontend e adicione os seguintes scripts:

{
  "scripts": {
    "dev": "quasar dev -m ssr",
    "build": "quasar build -m ssr"
  }
}

E para que possamos testar, modifique o package.json > scripts do monorepo:
./package.json

{
  "private": true,
  "workspaces": {
    "packages": ["backend", "frontend"]
  },
  "scripts": {
    "backend:dev": "yarn workspace backend build:dev",
    "backend:build": "yarn workspace backend build",
    "backend:start": "yarn workspace backend start",
    "frontend:dev": "yarn workspace frontend dev",
    "start": "yarn backend:start",
    "dev": "concurrently \"yarn backend:dev\" \"yarn frontend:dev\"",
    "postinstall": "yarn backend:build"
  }
}

Então execute:

yarn dev

Então acesse http://localhost:8080 para verificar que o frontendestá funcionando, então http://localhost:8080/api/docs para verificar que o backend está em ordem.

QPANC - Parte 20 - Docker - Traefik e Publicação

Tobias Mesquita — Sun, 19 Apr 2020 23:39:33 +0000

40 Configurando os serviços na VM

Para orquestrar as requisições na VM, iremos utilizar o traefik, porém iremos utilizar autenticação basic para proteger o seu painel, desta forma, precisamos primeiro codificar uma senha, para tal, execute o seguinte comando na terminal SSH conectado a VM.

sudo apt-get install apache2-utils
echo $(htpasswd -nb ${user} ${password}) | sed -e s/\\$/\\$\\$/g

por exemplo, para o usuario qpanc e a senha exposed:

echo $(htpasswd -nb qpanc exposed) | sed -e s/\\$/\\$\\$/g

qpanc:$$apr1$$U0UpF78N$$3AxgB876rR09fJ5OuylKk/

Agora, podemos montar o compose.yml que será utilizado na VM:

version: '3.4'

services:
  qpanc.api:
    restart: always
    container_name: qpanc_api
    depends_on:
      - qpanc.database
    image: qpanc.azurecr.io/api:latest
    ports:
      - "34512:80"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.3"
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ASPNETCORE_URLS=http://+:80
      - DEFAULT_CONNECTION=Server=qpanc.database;Port=5432;Database=postgres;User Id=postgres;Password=keepitsupersecret;
      - JWTBEARER_VALIDISSUER=https://api.your_domain.com/
      - JWTBEARER_VALIDAUDIENCE=https://api.your_domain.com/
      - JWTBEARER_ISSUERSIGNINGKEY=itUXC7iVRsofSDWNeg/aLYpc4bMzHAsMPzeItE1PQi2tMK2f4t0InRgTE5B/4IAjhAX5LQSIGL1CaUHSSzED8A==
      - JWTBEARER_TOKENDECRYPTIONKEY=7hfboHG0d4GnXjVng0ukMo+IgrKKrPLUMtOvnt4S514=
      - CORS_HOSTS__0=your_domain.com
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.qpanc_api.loadbalancer.server.port=80"
      - "traefik.http.routers.qpanc_api.rule=Host(`api.your_domain.com`)"
      - "traefik.http.routers.qpanc_api.entrypoints=web"
      - "traefik.http.routers.qpanc_api.service=qpanc_api"
      - "traefik.http.routers.qpanc_api-secure.rule=Host(`api.your_domain.com`)"
      - "traefik.http.routers.qpanc_api-secure.tls=true"
      - "traefik.http.routers.qpanc_api-secure.tls.certresolver=le"
      - "traefik.http.routers.qpanc_api-secure.entrypoints=websecure"
      - "traefik.http.routers.qpanc_api-secure.service=qpanc_api"
      - "traefik.docker.network=external_network"

  qpanc.app:
    restart: always
    container_name: qpanc_app
    image: qpanc.azurecr.io/app:latest
    ports:
      - "34515:3000"
    volumes:
      - webapp:/app
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.6"
    labels:
      - "traefik.enable=true"
      - "traefik.http.services.qpanc_app.loadbalancer.server.port=3000"
      - "traefik.http.routers.qpanc_app.rule=Host(`your_domain.com`)"
      - "traefik.http.routers.qpanc_app.entrypoints=web"
      - "traefik.http.routers.qpanc_app.service=qpanc_app"
      - "traefik.http.routers.qpanc_app-secure.rule=Host(`your_domain.com`)"
      - "traefik.http.routers.qpanc_app-secure.tls=true"
      - "traefik.http.routers.qpanc_app-secure.tls.certresolver=le"
      - "traefik.http.routers.qpanc_app-secure.entrypoints=websecure"
      - "traefik.http.routers.qpanc_app-secure.service=qpanc_app"
      - "traefik.docker.network=external_network"

  qpanc.database:
    restart: always
    image: postgres:latest
    ports:
      - "34514:5432"
    volumes:
      - database:/var/lib/postgresql/database
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.9"
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: keepitsupersecret
      POSTGRES_DB: postgres

  traefik:
    container_name: traefik
    image: traefik:latest
    depends_on:
      - qpanc.app
      - qpanc.api
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.12"
    command:
      - "--api=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.traefik.address=:8080"
      - "--certificatesResolvers.le.acme.email=your_email@provider.com"
      - "--certificatesResolvers.le.acme.storage=acme.json"
      - "--certificatesResolvers.le.acme.tlsChallenge=true"
      - "--certificatesResolvers.le.acme.httpChallenge=true"
      - "--certificatesResolvers.le.acme.httpChallenge.entryPoint=web"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/acme.json:/acme.json
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.rule=Host(`traefik.your_domain.com`)"
      - "traefik.http.routers.traefik.service=api@internal"
      - "traefik.http.routers.traefik.middlewares=admin"
      - "traefik.http.routers.traefik.tls.certresolver=le"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.middlewares.admin.basicauth.users=qpanc:$$apr1$$U0UpF78N$$3AxgB876rR09fJ5OuylKk/"

volumes:
  webapp:
  database:

networks:
  qpanc.internal:
    internal: true
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.18.18.0/24
  qpanc.network:

Não esqueça de atualizar o label traefik.http.middlewares.admin.basicauth.users, afinal, você não vai querer usar a senha exposed

Ele é basicamente a combinação do QPANC/docker-compose.yml e do QPANC/docker-compose.production.yml, porém sem a parte do build.

A outra diferença, é que agora estamos a configurar o traefik, é ele que irá receber todas as requisições e transferir para o serviço apropriado.

Por exemplo, as requisições feitas para o host traefik.your_domain.com serão redirecionadas para o painel do traefik. as feitas ao host api.your_domain.com irão para à API e por fim, as feitas para qpanc.your_domain.com para o app feito usando o Quasar.

Outro ponto importante, é que traefik é responsavel por configurar o SSL, gerenciando a integração com o Let's Encrypt. porém, precisamos de um domínio valido para isto.

Dado estas informações, conecte à VM usando o SSH, crie o arquivo data/acme.json, e modifique o seu nível de acesso para 600:

mkdir data
cd data
> acme.json
touch acme.json
chmod 600 acme.json
cd ..

Agora, vamos criar o aquivo docker-compose.yml:

sensible-editor docker-compose.yml

Caso pergunte qual é o editor da sua preferencia, na duvida escolha o nano.
Então, copie o conteúdo do docker-compose acima, apenas lembre-se de alterar o your_mail@provider.com para o seu email e your_domain.com para o endereço da aplicação.

Após salvar o docker-compose.yml, precisamos garantir que o docker-compose up será executado sempre que a VM for inicializada:

sudo systemctl enable docker

E antes de podemos levantar os nossos serviços, precisamos logar no docker usando uma conta que possa baixar as imagens:

docker login -u ${username} -p ${password} ${login_server}

no meu caso:

docker login -u qpanc -p ************************ qpanc.azurecr.io

E agora levante os serviços

sudo docker-compose up -d

Caso precise atualizar os serviços, podemos executar um script como o seguinte:

sudo docker-compose down
sudo docker pull qpanc.azurecr.io/api:latest
sudo docker pull qpanc.azurecr.io/app:latest
sudo docker-compose up -d

QPANC - Parte 19 - Docker - Registro e Build

Tobias Mesquita — Sun, 19 Apr 2020 23:39:31 +0000

38 Criando um Container Registry no Azure.

para podemos continuar, iremos precisar de um Container Registry, novamente, você pode usar qual quer provedor, como por exemplo, o Docker Hub porém estarei criando um no azure.

Então comece o processo para adicionar um novo recurso, e busque por Container Registry:

É interessante que o Container Registry use o mesmo grupo de recursos e esteja localizado na mesma região que a VM, assim como estaremos ativando o usuário admin, e como estamos criando este registro apenas para testes, use o SKU Basic.

Agora à confirmação da criação do registro, precisamos esperar alguns instantes, até que o azure configure tudo.

Por fim, vá até a guia Access Keys e copie o nome do Login server, username e o password.

Agora, temos um registro para onde podemos enviar as nossas imagens.

39 Fazendo o Build para produção

Antes de realizamos o build para produção, precisamos desativar o redirecionamento HTTPS da API, pois este procedimento será feito por outro serviço, o traefik.

então, no docker-compose.yml remova qual quer referencia à porta 443.

- "34513:443" => // remova completamente esta linha
- ASPNETCORE_URLS=http://+:443;http://+:80 => - ASPNETCORE_URLS=;http://+:80

E no QPANC.Api/Startup.cs, remova a seguinte linha:

app.UseHttpsRedirection();

Então, faça uma copia do docker-compose.override.yml e renomeie ela para docker-compose.production.yml.

QPANC/docker-compose.production.yml

version: '3.4'

services:
  qpanc.api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ASPNETCORE_URLS=https://+:443;http://+:80
      - DEFAULT_CONNECTION=Server=qpanc.database;Port=5432;Database=postgres;User Id=postgres;Password=keepitsupersecret;
      - JWTBEARER_VALIDISSUER=https://api.qpanc.tobiasmesquita.dev/
      - JWTBEARER_VALIDAUDIENCE=https://api.qpanc.tobiasmesquita.dev/
      - JWTBEARER_ISSUERSIGNINGKEY=itUXC7iVRsofSDWNeg/aLYpc4bMzHAsMPzeItE1PQi2tMK2f4t0InRgTE5B/4IAjhAX5LQSIGL1CaUHSSzED8A==
      - JWTBEARER_TOKENDECRYPTIONKEY=7hfboHG0d4GnXjVng0ukMo+IgrKKrPLUMtOvnt4S514=
      - CORS_HOSTS__0=qpanc.tobiasmesquita.dev
    ports:
      - "34512:80"
      - "34513:443"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro

  qpanc.app:
    container_name: qpanc_app_prod
    build:
      context: ./QPANC.App
      target: 'prod-stage'
      dockerfile: .docker/prod.Dockerfile
    volumes:
      - app:/app
    ports:
      - "34514:3000"

  qpanc.database:
    volumes:
      - database:/var/lib/postgresql/database
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: keepitsupersecret
      POSTGRES_DB: postgres

volumes:
  app:
  database:

No service qpanc.api nós alteramos o environment, adicionando algumas variáveis de ambiente e modificando outras: ASPNETCORE_ENVIRONMENT, JWTBEARER_VALIDISSUER, JWTBEARER_VALIDAUDIENCE e CORS_HOSTS__0.

No service qpanc.app, temos mais alterações, a primeira é o nome do contêiner em container_name: qpanc_app_prod, no caso do build, estamos usando um outro Dockerfile, nos volumes, app vai está apontando para um volume interno, na porta, estaremos usando a porta 3000 ao invés de 8080, assim como, foi removido o commands.

Por fim, o qpanc.database teve alterações menos relevantes, como o volumes e o container_name.

O próximo passo, é preparar o prod.Dockerfile

QPANC.App/.docker/prod.Dockerfile

# develop stage
FROM node:12.16-alpine as develop-stage
WORKDIR /app/source
COPY package*.json ./
RUN npm i -g @quasar/cli@latest
COPY . .

# local-deps
FROM develop-stage as local-deps-stage
RUN ls
RUN rm -r -f .quasar
RUN rm -r -f dist
RUN rm -r -f node_moduless
RUN rm -f yarn.lock
RUN yarn

# build stage
FROM local-deps-stage as build-stage
ENV API_CLIENT_URL=https://api.qpanc.tobiasmesquita.dev/
ENV API_SERVER_URL=https://api.qpanc.tobiasmesquita.dev/
RUN quasar build -m ssr

# prod stage
FROM build-stage as prod-stage
WORKDIR /app/source/dist/ssr
RUN mv * ../../../
WORKDIR /app
RUN rm -r -f source
RUN yarn
CMD ["node", "index.js"]

Basicamente, estamos copiando o source, apagando node_moduless, dist, locks, e baixamos novamente, então é feito o build, copiamos os arquivos do build para a raiz, por fim apagamos o source

Agora, execute o seguinte comando.:

docker-compose -f docker-compose.yml -f docker-compose.production.yml build
docker image ls -a

Vai levar alguns longos segundos, para que o build do app e da api seja realizado, então devemos anotar o ID das imagens, no meu caso 516a0d428a28para a api e eb3ec1b5548e para o app.

Então, execute o seguinte comando para o app e para a api, para que consigamos criar as suas respectivas tags.

docker tag {image} {registry_name}/{container_name}:{tag_name}

no meu caso:

docker tag 516a0d428a28 qpanc.azurecr.io/api:latest
docker tag eb3ec1b5548e qpanc.azurecr.io/app:latest
docker image ls -a

Agora que criamos as nossas imagens e as suas respectivas tags, precisamos subir relas para o container, para que isto seja possível, teremos de logar no docker usando uma conta com permissão:

docker login -u ${username} -p ${password} ${login_server}

no meu caso

docker login -u qpanc -p ************************ qpanc.azurecr.io

agora que efetuamos o login, podemos fazer o push das imagens, então execute o seguinte comando, tanto para o app como para a api.

docker push {registry_name}/{container_name}:{tag_name}

no meu caso

docker push qpanc.azurecr.io/api:latest
docker push qpanc.azurecr.io/app:latest

Feito isto, as imagens já estão disponíveis, já podemos ser acessadas a partir da VM

Caso tenha feito o upload para um Registro criado no portal do Azure, eles vão ser listados da seguinte forma:

Note que latest é o valor default para as tags, porém é interessante, que a cada publicação seja criado uma nova tag, como por exemplo 1.0.0, 1.0.1 ou 1.1.0, e a latest deverá ser apenas um alias para a mais recente.

Por fim, deixo um script que fazer a limpeza dos containers/imagens, faz o build, cria as tags e realiza o upload. Porém que fique claro, que esta solução é um tanto quanto drástica.

docker container stop $(docker container ls -aq)
docker container rm $(docker container ls -aq)
docker image rm $(docker image ls -aq) -f
docker-compose -f docker-compose.yml -f docker-compose.production.yml build --no-cache --force-rm --compress
docker tag $(docker image ls -f=reference="qpancapi" -q) qpanc.azurecr.io/api:latest
docker tag $(docker image ls -f=reference="qpancapp" -q) qpanc.azurecr.io/app:latest
docker push qpanc.azurecr.io/api:latest
docker push qpanc.azurecr.io/app:latest

QPANC - Parte 18 - Docker - Maquina Virtual Linux

Tobias Mesquita — Sun, 19 Apr 2020 23:39:29 +0000

36 Configurando uma VM no Azure

Para publicar, iremos utilizar uma VM no Azure, de toda forma, você poderá optar por qual quer VPS, como as da Digital Ocean, AWS, Hostiger, Hostgator, Locaweb, dentre outros. Neste ponto, a unica exigência, é ser capaz de e conectar usando SSH e conseguir instalar o docker.

No caso do azure, você pode se inscrever no programa Dev Essentials, então acesse o site My Visual Studio e ative o seu beneficio.

O próximo passo é criar uma maquina virtual, para tal acesse https://portal.azure.com/ e adicione um novo recurso.

Procure por Ubuntu Server LTS

Na primeira aba, preencha os dados básicos sobre a VM, tipo o grupo de recursos, localização, tamanho, etc. Para fiz de testes, aconselho que selecione uma VM da serie B, para produção, o ideal é uma VM da Serie D.

Ainda na mesma aba, defina um usuário e uma senha, não esqueça de liberar as portas, especialmente a 443 (SSL) e a 22 (SSH).

Na aba Network, certifique-se que o IP selecionado é Static

Por fim, na aba Review + Create, revise a VM e crie ela, então aguarde até que a VM esteja disponível.

Acesse a VM recém criada, então certifique que o IP é estático, copie o IP e defina um nome de DNS:

Opcionalmente, você pode mapear o IP desta VM para um endereço na Web, para fazer isto pelo Azure, crie uma DNS Zone, e adicione o registro.:

37 Instalando o Docker na VPS.

O primeiro passo é conectar na VPS, para isto abra o terminal (estou usando o PS6), e execute o seguinte comando:

ssh ${user_name}@${dns_address}

ssh ${user_name}@${ip}

No meu caso:

ssh qpanc@qpanc.eastus2.cloudapp.azure.com

Aceite o certificado e informe a senha (você definiu esta senha durante a criação da VM).

Feito isto, agora é hora de instalar o docker:

sudo apt-get update
sudo apt-get install docker.io
sudo docker -v

Agora, precisamos instalar o docker-compose, apenas NÃO caia na tentação de executar sudo apt-get install docker-compose, pois isto irá instalar uma versão bem antiga, ao invés disto, execute os seguintes comandos:

sudo curl -L "https://github.com/docker/compose/releases/download/1.27.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
sudo docker-compose -v

QPANC - Parte 17 - Quasar - Registro

Tobias Mesquita — Sun, 19 Apr 2020 23:38:52 +0000

35 Registrar Usuário.

Antes de criamos o componente de registro, precisamos adicionar duas novas regras de validação no validations.js

QPANC.App/src/services/validations.js

validations.compare = ({ self, field }) => {
  return function required (val) {
    var other = self.validationArgs[field].compare
    return val === self[other] || self.$t('validations.compare', {
      field: self.$t(`fields.${field}`),
      other: self.$t(`fields.${other}`)
    })
  }
}

validations.strength = ({ self, field }) => {
  return function required (val) {
    const property = self.validationArgs[field].strength
    const strength = self[property]
    return strength < 0.6 || self.$t('validations.strength', {
      field: self.$t(`fields.${field}`)
    })
  }
}

A regra compare serve para comprar o valor de dois campos, o campo other é definido no validationArgs.compare.

A regra strength testa a força de uma senha, no caso, este valor varia de 0 à 1, por hora, iremos definir um valor de 0.6 como aceitável, o validationArgs.strength possui o nome da propriedade computada que realiza o calculo.

Agora, precisamos instalar o pacote zxcvbn, pois iremos utiliza-lo para validar a força da senha:

yarn add zxcvbn

Então, podemos criar a nossa pagina de registro

QPANC.App/src/pages/home/store.js

import { factory } from '@toby.mosque/utils'
import { Dialog } from 'quasar'

class RegisterPageModel {
  constructor ({
    userName = '',
    confirmUserName = '',
    firstName = '',
    lastName = '',
    password = '',
    confirmPassword = ''
  } = {}) {
    this.userName = userName
    this.confirmUserName = confirmUserName
    this.firstName = firstName
    this.lastName = lastName
    this.password = password
    this.confirmPassword = confirmPassword
  }
}

const options = {
  model: RegisterPageModel
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    },
    async register ({ state }) {
      await this.$axios.post('/Auth/Register', state)
      this.$router.push('/login')
      Dialog.create({
        color: 'positive',
        message: this.$t('register.success')
      })
    }
  }
})

export { options, RegisterPageModel }

Na store não há nada de novo.

QPANC.App/src/pages/home/index.js

import validations from 'services/validations'
import { factory } from '@toby.mosque/utils'
import store, { options } from './store'
import zxcvbn from 'zxcvbn'

const moduleName = 'page-register'
export default factory.page({
  name: 'RegisterPage',
  options,
  moduleName,
  storeModule: store,
  created () {
    if (process.env.CLIENT) {
      this.$root.$on('unprocessable', this.unprocessable)
    }
  },
  destroy () {
    if (process.env.CLIENT) {
      this.$root.$off('unprocessable', this.unprocessable)
    }
  },
  data () {
    const self = this
    const validation = validations(self, {
      userName: ['required', 'email', 'server'],
      confirmUserName: ['required', 'compare', 'email'],
      firstName: ['required'],
      lastName: ['required'],
      password: ['required', 'strength', 'server'],
      confirmPassword: ['required', 'compare']
    })
    return {
      validation,
      validationArgs: {
        userName: {
          server: true
        },
        confirmUserName: {
          compare: 'userName'
        },
        password: {
          server: true
        },
        confirmPassword: {
          compare: 'password'
        }
      }
    }
  },
  computed: {
    strength () {
      if (!this.password) {
        return 0
      }
      const strength = zxcvbn(this.password).score + 1
      return strength / 5
    },
    strColor () {
      switch (this.strength) {
        case 1: return 'blue'
        case 0.8: return 'green'
        case 0.6: return 'yellow'
        case 0.4: return 'orange'
        case 0.2: return 'red'
        default: return 'grey'
      }
    }
  },
  methods: {
    unprocessable (errors) {
      switch (true) {
        case !!errors.UserName: this.validationArgs.userName.server = errors.UserName[0]; break
        case !!errors.Password: this.validationArgs.password.server = errors.Password[0]; break
      }
      this.$refs.form.validate()
    },
    async register () {
      this.validation.resetServer()
      const isValid = await this.$refs.form.validate()
      if (isValid) {
        this.$store.dispatch(`${moduleName}/register`)
      }
    }
  }
})

No script do componente, você pode observar o data, onde agora temos as regras compare e strength, e no confirmUserName estamos a definir as depedencias para estas validações.

No computed, temos o strength e strColor, que é utilizado para mensurar a força do password.

QPANC.App/src/pages/home/index.sass

#page-register

QPANC.App/src/pages/home/index.vue

<template>
  <div id="page-register">
    <h5 class="q-my-md">{{$t('register.title')}}</h5>
    <q-separator></q-separator>
    <q-form ref="form" class="row q-col-gutter-sm">
      <div class="col col-12">
        <q-input v-model="userName" :label="$t('fields.userName')" :rules="validation.userName" @blur="validationArgs.userName.server = true"></q-input>
      </div>
      <div class="col col-12">
        <q-input v-model="confirmUserName" :label="$t('fields.confirmUserName')" :rules="validation.confirmUserName"></q-input>
      </div>
      <div class="col col-12">
        <q-input v-model="firstName" :label="$t('fields.firstName')" :rules="validation.firstName"></q-input>
      </div>
      <div class="col col-12">
        <q-input v-model="lastName" :label="$t('fields.lastName')" :rules="validation.lastName"></q-input>
      </div>
      <div class="col col-12">
        <q-input type="password" v-model="password" :label="$t('fields.password')" :rules="validation.password" @blur="validationArgs.password.server = true"></q-input>
        <q-linear-progress size="10px" stripe :value="strength" :color="strColor" ></q-linear-progress>
      </div>
      <div class="col col-12">
        <q-input type="password" v-model="confirmPassword" :label="$t('fields.confirmPassword')" :rules="validation.confirmPassword"></q-input>
      </div>
      <div class="col col-5">
        <q-btn class="full-width" color="secondary" :label="$t('actions.backLogin')" to="/login"></q-btn>
      </div>
      <div class="col col-7">
        <q-btn class="full-width" color="positive" :label="$t('actions.register')" @click="register"></q-btn>
      </div>
    </q-form>
  </div>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

A unica novidade aqui, é a presença do QLinearProgress.

E agora, um vídeo com o processo de registro e login

QPANC - Parte 16 - Quasar - Áreas Protegidas

Tobias Mesquita — Sun, 19 Apr 2020 23:38:51 +0000

33 Área Principal/Protegida - Parte I.

Agora, precisamos criar um segundo layout, que será utilizado pelas paginas protegidas.

Iremos adicionar a fonte mdi-v5, por ele ter um maior leques de ícones que a fonte oficial do google, isto será feito em quasar.config.js > extras > mdi-v5.

module.exports = function (ctx) {
  return {
    extras: [
      'mdi-v5'
    ]
  }
}

Então crie a pasta main em QPANC.App/src/layouts e adicione os arquivos store.js, index.js, index.sass e index.vue

QPANC.App/src/layouts/main/store.js

import { factory } from '@toby.mosque/utils'

class MainLayoutModel {
  constructor ({
    leftDrawerOpen = false
  } = {}) {
    this.leftDrawerOpen = leftDrawerOpen
  }
}

const options = {
  model: MainLayoutModel
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    },
    async logout (context) {
      await this.$axios.delete('/Auth/Logout')
      commit('app/token', undefined, { root: true })
      this.$router.push('/login')
    }
  }
})

export { options, MainLayoutModel }

QPANC.App/src/layouts/main/index.js

import EssentialLink from 'components/EssentialLink'
import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'layout-main'
export default factory.page({
  name: 'MainLayout',
  options,
  moduleName,
  storeModule: store,
  components: {
    EssentialLink
  },
  data () {
    return {
      essentialLinks: [
        {
          title: 'Docs',
          caption: 'quasar.dev',
          icon: 'school',
          link: 'https://quasar.dev'
        },
        {
          title: 'Github',
          caption: 'github.com/quasarframework',
          icon: 'code',
          link: 'https://github.com/quasarframework'
        },
        {
          title: 'Discord Chat Channel',
          caption: 'chat.quasar.dev',
          icon: 'chat',
          link: 'https://chat.quasar.dev'
        },
        {
          title: 'Forum',
          caption: 'forum.quasar.dev',
          icon: 'record_voice_over',
          link: 'https://forum.quasar.dev'
        },
        {
          title: 'Twitter',
          caption: '@quasarframework',
          icon: 'rss_feed',
          link: 'https://twitter.quasar.dev'
        },
        {
          title: 'Facebook',
          caption: '@QuasarFramework',
          icon: 'public',
          link: 'https://facebook.quasar.dev'
        }
      ]
    }
  },
  methods: {
    logout () {
      return this.$store.dispatch('layout-main/logout')
    }
  }
})

QPANC.App/src/layouts/main/index.sass

#layout-main

QPANC.App/src/layouts/main/index.html

<template>
  <q-layout id="layout-main" view="lHh Lpr lFf" class="bg-main">
    <q-header elevated>
      <q-toolbar>
        <q-btn
          flat
          dense
          round
          icon="menu"
          aria-label="Menu"
          @click="leftDrawerOpen = !leftDrawerOpen"
        />

        <q-toolbar-title>
          Quasar App
        </q-toolbar-title>

        <div>
          Quasar v{{ $q.version }}
          <q-btn flat icon="mdi-exit-to-app" label="logout" @click="logout"></q-btn>
        </div>
      </q-toolbar>
    </q-header>

    <q-drawer
      v-model="leftDrawerOpen"
      show-if-above
      bordered
      content-class="bg-content"
    >
      <q-list>
        <q-item-label header>
          Essential Links
        </q-item-label>
        <EssentialLink
          v-for="link in essentialLinks"
          :key="link.title"
          v-bind="link"
        />
      </q-list>
    </q-drawer>

    <q-page-container>
      <router-view />
    </q-page-container>
  </q-layout>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

Note que, este é basicamente o layout padrão do quasar, adaptado para o modo dark/light e com a função de logout.

E agora, vamos adicionar a nossa primeira pagina que irá utilizar este layout. Crie a pasta home na pasta QPANC.App/src/pages e adicione os arquivos store.js, index.js, index.sass e index.vue

QPANC.App/src/pages/home/store.js

import { factory } from '@toby.mosque/utils'

class HomePageModel {
}

const options = {
  model: HomePageModel
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    }
  }
})

export { options, HomePageModel }

QPANC.App/src/pages/home/index.js

import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'page-home'
export default factory.page({
  name: 'HomePage',
  options,
  moduleName,
  storeModule: store
})

QPANC.App/src/pages/home/index.sass

#page-home

QPANC.App/src/pages/home/index.vue

<template>
  <q-page id="page-home" class="flex flex-center">
    Home
  </q-page>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

tanto trabalho para exibir a palavra Home, mas precisávamos de uma pagina apenas.

Agora, crie o arquivo main.js na pasta QPANC.App/src/router/areas e adicione as seguintes rotas.

QPANC.App/src/router/areas/main.js

export default function (context) {
  return {
    path: '',
    component: () => import('layouts/main/index.vue'),
    children: [
      { name: 'home', path: 'home', component: () => import('pages/home/index.vue') }
    ],
    meta: {
      authorize: true
    }
  }
}

Note a presença do meta, nós usamos este campo, quando queremos adiciona alguma informação de controle a rota, neste caso, que o usuário precisa está logado para acessar este componente (e os seus respectivos filhos).

inclua a área main no arquivo routes.js:

QPANC.App/src/router/routes.js

import clean from './areas/clean'
import main from './areas/main'

export default function (context) {
  const routes = [{
    path: '/',
    component: { /* ... */ },
    children: [
      {
        path: '',
        beforeEnter (to, from, next) { /* ... */ }
      },
      clean(context),
      main(context)
    ]
  }]

  // Always leave this as last one
  if (process.env.MODE !== 'ssr') { /*...*/ }

  return routes
}

E agora vamos criar um navigation guard global, que fará uso do meta authorize, para isto, precisamos fazer a seguinte alteração no index.js.

QPANC.App/src/router/index.js

/* ... */

export default function (context) {
  context.router = new VueRouter({ /*...*/ })

  context.router.beforeEach((to, from, next) => {
    const { store } = context
    let protectedRoutes = to.matched.filter(route => route.meta.authorize)
    if (protectedRoutes.length > 0) {
      const logged = store.getters['app/isLogged']()
      if (!logged) {
        next('/login')
      }
    }
    next()
  })
  return context.router
}

Então execute a aplicação e tente acessar a raiz da aplicação (rota '/'), e veja que seja redirecionado para '/login' se não estiver logado e '/home' se estiver.

Caso coloque um console.log({ path: to.path, authorize: requireAuth }) no beforeEach, você verá que para o path '/' o protectedRoutes.length será 0.

Caso tente acessar a pagina de login (rota /login) enquanto logado, você terá acesso a esta rota, o que é esperado.

Caso tente acessar a pagina home (rota /home) enquanto não está logado, você será enviado para a rota /login, o que também é esperado.

34 Área Principal/Protegida - Parte 2.

Agora, iremos cria uma segunda pagina, só que para acessar esta pagina, o usuário além de autenticado, precisa está autorizado, neste caso, a autorização é feita apenas para os usuários que tenham a role Developer

O primeiro passo, é criar uma nova page, copie a pasta home e renomeie a copia para devboard, e claro, em prol da consistência, não esqueça de renomear qual quer incidência da palavra home para devboard.

Agora que temos um componente, temos que criar um rota para ele, isto será feito no arquivo main.js em QPANC.App/src/router/areas

QPANC.App/src/router/areas/main.js

export default function (context) {
  return {
    path: '',
    component: () => import('layouts/main/index.vue'),
    children: [
      { name: 'home', path: 'home', component: () => import('pages/home/index.vue') },
      {
        name: 'devboard',
        path: 'devboard',
        component: () => import('pages/devboard/index.vue'),
        meta: {
          authorize: {
            roles: ['Developer']
          }
        }
      }
    ],
    meta: {
      authorize: true
    }
  }
}

Note que os meta authorize, tentam ter o mesmo comportamento que o AuthorizeAttribute no C#, desta forma, todos os componentes com authorize serão testando, o que na pratica combina todos os authorize.

O segundo ponto, é que no campo roles é possível declarar múltiplas role, porém teremos um OR e não um AND. exemplo, se tivemos ['Developer', 'Admin'], então basta que o usuário seja um Admin ou Developer para ter acesso a esta rota.

O próximo passo, é incluir alguns getters na store app, estes getters serão responsável por testar de o usuário possui algumas das roles declaradas.

QPANC.App/src/store/app.js

import { factory } from '@toby.mosque/utils'

/*...*/

const roleClaimName = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/role'
export default factory.store({
  options,
  getters: {
    /*...*/
    roles (state, getters) {
      if (!getters.decoded || !getters.decoded.exp) {
        return []
      }
      const roles = getters.decoded[roleClaimName]
      if (Array.isArray(roles)) {
        return roles
      } else {
        return [roles]
      }
    },
    isOnRoles (state, getters) {
      return (roles) => {
        return getters.roles.some(role => roles.include(role))
      }
    }
  }
})

Note que, ao decompor o token JWT, o campo http://schemas.microsoft.com/ws/2008/06/identity/claims/role poderá ser um array ou uma string, caso ele seja uma string, devemos retornar um array tendo ele como único elemento.

O getter isOnRoles testa se o usuário logado possui pelo menos uma role que pertença a lista de roles passada.

Agora, precisamos fazer uma alteração no beforeEach que está no index.js em QPANC.App/src/router, para que ele faça uso dos novos getters.

QPANC.App/src/router/index.js

router.beforeEach((to, from, next) => {
  const { store } = context
  let protectedRoutes = to.matched.filter(route => route.meta.authorize)
  if (protectedRoutes.length > 0) {
    const logged = store.getters['app/isLogged']()
    if (!logged) {
      return next('/login')
    }

    protectedRoutes = protectedRoutes.filter(route => route.meta.authorize.roles)
    if (protectedRoutes.length > 0) {
      for (const protectedRoute of protectedRoutes) {
        const { roles } = protectedRoute.meta.authorize
        const isOnRoles = store.getters['app/isOnRoles'](roles)
        if (!isOnRoles) {
          return next('/home')
        }
      }
    }
  }
  next()
})

Perceba que, caso o usuário não esteja logado, e tenta acessar uma área que requer autenticação, ele será redirecionado para a tela de login, porém se estiver logado, mas não tenha autorização, ele seja redirecionado para a tela inicial (home).

E para testamos este fluxo, iremos criar um QBtn na pagina home, que deve ser visível apenas para usuários com a role Developer

QPANC.App/src/pages/home/index.vue

<template>
  <q-page id="page-home" class="flex flex-center">
    Home
    <template v-if="isDeveloper">
      <q-btn to="/devboard" :label="$('actions.devboard')" />
    </template>
  </q-page>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

QPANC.App/src/pages/home/index.js

import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'page-home'
export default factory.page({
  name: 'HomePage',
  options,
  moduleName,
  storeModule: store,
  computed: {
    isOnRoles () {
      return this.$store.getters['app/isOnRoles']
    },
    isDeveloper () {
      return this.isOnRoles(['Developer'])
    }
  }
})

Quasar.App/src/i18n/en-us/index.js

export default {
  actions: {
    devboard: 'Developer Board'
  }
}

Quasar.App/src/i18n/pt-br/index.js

export default {
  actions: {
    devboard: 'Painel do Desenvolvedor'
  }
}

Agora, acesse a pagina Home, e desde que seja um Developer, você verá um QBtn que irá redirecionar para a pagina Devboard.

Agora, tente alterar a regra de autorização, para ao invés de testar se o usuário é um Developer, testar se é ele um Admin (estou suponto que o seu usuário não é um Admin).

Neste caso, o QBtn da pagina Home deverá desaparecer, e caso tente acessar a pagina Devboard diretamente, será redirecionado para a Home, como este redirecionamento é feito no servidor, a pagina Devboard sequer será renderizada.

QPANC - Parte 15 - Quasar - Login

Tobias Mesquita — Sun, 19 Apr 2020 23:38:49 +0000

31 - Componente de Login - Part 2

Agora que terminamos de configurar os boots, podemos retornar ao componente de Login, e fazer a integração dele com a API.

O primeiro passo, é adicionar a escuta ao evento unprocessable, que é emitido pelo axios sempre que ocorre um erro 422.

QPANC.App/src/pages/login/index.js

export default factory.page({
  name: 'LoginPage',
  created () {
    if (process.env.CLIENT) {
      this.$root.$on('unprocessable', this.unprocessable)
    }
  },
  destroy () {
    if (process.env.CLIENT) {
      this.$root.$off('unprocessable', this.unprocessable)
    }
  },
  methods: {
    unprocessable (errors) {
      console.log(errors)
    }
  }
})

O segundo passo, é adicionar a regra server aos campos que sofrem validação.:

QPANC.App/src/pages/login/index.js

export default factory.page({
  name: 'LoginPage',
  data () {
    const self = this
    const validation = validations(self, {
      userName: ['required', 'email', 'server'],
      password: ['required', 'server']
    })
    return {
      validation,
      validationArgs: {
        userName: {
          server: true
        },
        password: {
          server: true
        }
      }
    }
  },
})

Como as validações feitas sobre o userName no lado do servidor também são realizadas pelo front e de se esperar que a API nunca retorne um erro para este campo. Então, você pode remover esta validação ou manter.

Agora, adicione o evento @blur=validationArgs.${name}.server = true aos componentes que são validados no servidor.:

QPANC.App/src/pages/login/index.vue

    <q-form ref="form" class="row q-col-gutter-sm">
      <div class="col col-12">
        <q-input v-model="userName" :label="$t('fields.userName')" :rules="validation.userName" @blur="validationArgs.userName.server = true"></q-input>
      </div>
      <div class="col col-12">
        <q-input type="password" v-model="password" :label="$t('fields.password')" :rules="validation.password" @blur="validationArgs.password.server = true"></q-input>
      </div>
      ...
    </q-form>

Como as validações feitas no servidor são exibidas de forma estática, precisamos limpar elas manualmente, por isto a necessidade do evento @blur, assim como do this.validation.resetServer() antes de validar novamente.

QPANC.App/src/pages/login/index.js

export default factory.page({
  name: 'LoginPage',
  methods: {
    async login () {
      this.validation.resetServer()
      const isValid = await this.$refs.form.validate()
      if (isValid) {
        await this.$store.dispatch(`${moduleName}/login`)
      }
    }
  }
})

O ultimo passo, e atualizar o argumento server, sempre que o evento unprocessable ocorrer:

QPANC.App/src/pages/login/index.js

export default factory.page({
  name: 'LoginPage',
  methods: {
    unprocessable (errors) {
      switch (true) {
        case !!errors.UserName: this.validationArgs.userName.server = errors.UserName[0]; break
        case !!errors.Password: this.validationArgs.password.server = errors.Password[0]; break
      }
      this.$refs.form.validate()
    }
  }
})

Note que estamos chamando o this.$refs.form.validate(), para forçar que os campos sejam revalidados, assim exibindo a mensagem de erro.

Agora que o componente está aplicando as validações, tanto as feitas no lado do cliente, quanto as remotas, podemos fazer as alterações necessárias na store.

QPANC.App/src/pages/login/index.js

export default factory.store({
  actions: {
    async login ({ state, commit }) {
      const { data: token } = await this.$axios.post('/Auth/Login', state)
      commit('app/token', token, { root: true })
      this.$router.push('/home')
    }
  }
})

Caso ocorra algum erro na API, não precisa se preocupar, pois o interceptor do axios irá lidar com ele.

32 Lendo o Token JWT

Agora que já temos a nossa tela de Login, a já persistimos o token, precisamos adicionar uma forma de ler ele. para isto, iremos adicionar o pacote jwt-decode.

yarn add jwt-decode

O próximo passo é incrementar o nosso modulo app com alguns getters:

import { factory } from '@toby.mosque/utils'
import jwtDecode from 'jwt-decode'
class AppStoreModel {
  constructor ({
    token = '',
    localeOs = '',
    localeUser = ''
  } = {}) {
    this.token = token
    this.localeOs = localeOs
    this.localeUser = localeUser
  }
}

const options = {
  model: AppStoreModel
}

export default factory.store({
  options,
  getters: {
    decoded (state) {
      if (!state.token) {
        return undefined
      }
      return jwtDecode(state.token)
    },
    expireAt (state, getters) {
      if (!getters.decoded || !getters.decoded.exp) {
        return undefined
      }
      const expiration = getters.decoded.exp * 1000
      return new Date(expiration)
    },
    isLogged (state, getters) {
      return function () {
        const now = new Date()
        return getters.expireAt && getters.expireAt > now
      }
    },
    locale (state) {
      return state.localeUser || state.localeOs
    }
  }
})

export { options, AppStoreModel }

O getter decoded vai retornar o token decodificado, o getter expireAt vai retornar quando o token expira, e por fim o isLogged testa se a data de validade do token é maior do que agora.

Para o isLogged usamos um getter que retorna uma function ao invés de uma action, pois precisamos que este método seja chamado de forma síncrona. e actions são chamadas de forma assíncrona.

O isLogged retorna uma função ao invés de realizar o teste de forma direta, isto é necessário, por que o new Date não é reativo, desta forma ele seria executado apenas uma vez para cada token, fazendo que o token fosse sempre valido, mesmo expirado.

Uma forma de contornar isto, seria adicionar a hora atual ao state de outro modulo (não deve ser feito no app, para que esta data não seja persistida em um Cookie), então atualizar ele a cada segundo, porém isto adicionaria um custo extra, que seria justificável, caso precise exibir à hora atual na aplicação, ou tenhas mais regras que dependam a hora atual.

store/clock.js

import { factory } from '@toby.mosque/utils'
class CloseStoreModel {
  constructor ({
    now = '',
    interval = 0
  } = {}) {
    this.now = now || new Date().toISOString()
    this.interval = interval
  }
}

const options = {
  model: CloseStoreModel
}

export default factory.store({
  options,
  actions: {
    config ({ commit }) {
      if (process.env.CLIENT) {
        const interval = setInterval (() => {
          commit('now', new Date().toISOString())
        }, 1000)
        commit('interval', interval)
      }()
      return jwtDecode(state.token)
    },
    destroy ({ state, commit }) {
      clearInterval(state.interval)
      commit('interval', 0)
    }
  }
})

export { options, CloseStoreModel }

isLogged (state, getters, rootState) {
  const now = new Date(rootState.clock.now)
  return getters.expireAt && getters.expireAt > now
}

Note que no exemplo acima, armazenamos no state uma string no formato ISO, ao invés do objeto date, isto é necessário, pois é provável que o servidor esteja em um horário diferente do usuário, um outro complicador, é a implementação do Date, que é diferente no Browser (cliente) quando comparado ao NodeJS (servidor), desta forma, deve-se SEMPRE armazenar datas como strings nas stores e nunca como objetos.

Caso decida inspecionar os valores retornados por estes getters, pode fazer o seguinte.:

const logged = store.getters['app/isLogged']()
console.log({
  token: store.state.app.token,
  decoded: store.getters['app/decoded'],
  expireAt: store.getters['app/expireAt'],
  isLogged: store.getters['app/isLogged'],
  logged: logged
})

O resultado deverá ser algo semelhante ao exibido na imagem abaixo.:

E por fim, um exemplo de uso, vai condicionar o redirecionamento da rota '/' ao fato do usuário está logado ou não, para tal, vamos modificar o arquivo src/router/routes.js.

import clean from './areas/clean'

export default function (context) {
  const routes = [{
    path: '/',
    component: { /* ... */ },
    children: [
      {
        path: '',
        beforeEnter (to, from, next) {
          const { store } = context
          const logged = store.getters['app/isLogged']()
          if (logged) {
            next('/home')
          } else {
            next('/login')
          }
        }
      },
      clean(context)
    ]
  }]

  // Always leave this as last one
  if (process.env.MODE !== 'ssr') { /* ... */ }

  return routes
}

O nosso único impeditivo agora, é o fato que não temos uma rota /home.

QPANC - Parte 14 - Quasar - Consumindo a API

Tobias Mesquita — Sun, 19 Apr 2020 23:38:09 +0000

30 Axios

Durante a criação do projeto do Quasar, você pode optar por criar ou não o boot do axios, mas mesmo que tenha o criado, ele não está adequado para uma aplicação SSR.

O nosso primeiro passo, será configurar uma rede interna no arquivo de configuração do docker-compose, para que o aplicativo do Quasar possa se comunicar com a API.

QPANC/docker-compose.yml

services:
  qpanc.api:
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.3"

  qpanc.app:
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.6"

  qpanc.database:
    networks:
      qpanc.network:
      qpanc.internal:
        ipv4_address: "172.18.18.9"

networks:
  qpanc.internal:
    internal: true
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.18.18.0/24
  qpanc.network:

Durante o desenvolvimento, o comando quasar dev não é executado durante a construção da imagem, ele será executado quando tentamos levantar o container com a imagem de desenvolvimento.

por isto, precisamos setar as variáveis API_CLIENT_URL e API_SERVER_URL direto no comando, junto ao quasar dev. lembrando que esta alteração deve ser feita no docker-compose.override.yml.

QPANC/docker-compose.override.yml

services:
  qpanc.app:
    command: /bin/sh -c "yarn && API_CLIENT_URL=https://localhost:34513/ API_SERVER_URL=https://172.18.18.3:443/ quasar dev -m ssr"

Agora, precisamos modificar o quasar.config.js > build > extendWebpack, para injetamos a URL da API.

QPANC.App/quasar.config.js

const { DefinePlugin } = require('webpack')

module.exports = function (ctx) {
  return {
    build: {
      extendWebpack (cfg, { isServer }) {
        const definePlugin = cfg.plugins.find(plugin => plugin instanceof DefinePlugin)
        const apiUrl = JSON.stringify(isServer ? process.env.API_SERVER_URL : process.env.API_CLIENT_URL)
        definePlugin.definitions['process.env'].API_URL = apiUrl
      }
    }
  }
}

Estamos usando o extendWebpack, pois o API_URL deve ter um valor diferente no build: CLIENT quando comparado com o build: SERVER, quando não é necessário fazer esta diferenciação, podemos usar o quasar.config.js > build > env.

Agora, voltemos a nossa atenção para o boot do axios.

import axios from 'axios'
import inject from './inject'
import { Notify } from 'quasar'

export default inject(({ store, router }) => {
  const instance = axios.create({
    baseURL: process.env.API_URL
  })

  instance.interceptors.request.use((config) => {
    const token = store.state.app.token
    const locale = store.getters['app/locale']
    config.headers['Accept-Language'] = locale
    if (token) {
      config.headers.Authorization = `Bearer ${token}`
    }
    return config
  }, (error) => {
    return Promise.reject(error)
  })

  instance.interceptors.response.use((response) => {
    return response
  }, (error) => {
    const { status } = error.response || {}
    let message = store.$t('http.generic')
    switch (status) {
      case 400: message = store.$t('http.badRequest'); break
      case 401: message = store.$t('http.unauthorized'); break
      case 403: message = store.$t('http.forbidden'); break
      case 422:
        if (error.response.data) {
          const { title, errors } = error.response.data
          message = title
          message += '<ul>'
          for (const key in errors) {
            const error = errors[key]
            for (const msg of error) {
              message += '<li>' + msg + '</li>'
            }
          }
          message += '</ul>'
          store.$root.$emit('unprocessable', errors)
        } else {
          message = store.$t('http.unprocessable')
        }
        break
      case 500: message = store.$t('http.serverError'); break
      case 503: message = store.$t('http.serviceUnavailable'); break
    }
    Notify.create({
      type: 'negative',
      html: true,
      message: message
    })
    if (status === 401) {
      store.commit('app/token', undefined)
      router.push('/login')
    }
    return Promise.reject(error)
  })

  return {
    axios: instance
  }
})

Um pequeno detalhamento sobre o que está sendo feito acima:

  const instance = axios.create({
    baseURL: process.env.API_URL
  })

Aqui estamos verificando se estamos do lado do servidor ou do cliente, e criando uma instancia do axios com a URL apropriada.

  instance.interceptors.request.use((config) => {
    const token = store.state.app.token
    const locale = store.getters['app/locale']
    config.headers['Accept-Language'] = locale
    if (token) {
      config.headers.Authorization = `Bearer ${token}`
    }
    return config
  }, (error) => {
    return Promise.reject(error)
  })

Aqui estamos interceptando todas as requisições feitas com o axios, e adicionando o header de autenticação Authorization: Bearer ${token}, assim como a linguagem definida pelo usuário (que pode ser diferente da do browser/OS).

  instance.interceptors.response.use((response) => {
    return response
  }, (error) => {
    const { status } = error.response || {}
    let message = i18n.t('http.generic')
    switch (status) {
      case 400: message = store.$t('http.badRequest'); break
      case 401: message = store.$t('http.unauthorized'); break
      case 403: message = store.$t('http.forbidden'); break
      case 422:
        ...
        break
      case 500: message = store.$t('http.serverError'); break
      case 503: message = store.$t('http.serviceUnavailable'); break
    }
    Notify.create({
      type: 'negative',
      html: true,
      message: message
    })
    if (status === 401) {
      ...
    }
    return Promise.reject(error)
  })

Neste ponto, estamos interceptando as requisições que falharam, e exibindo uma notificação não intrusiva.

      case 422:
        if (error.response.data) {
          const { title, errors } = error.response.data
          message = title
          message += '<ul>'
          for (const key in errors) {
            const error = errors[key]
            for (const msg of error) {
              message += '<li>' + msg + '</li>'
            }
          }
          message += '</ul>'
          store.$root.$emit('unprocessable', errors)
        } else {
          message = store.$t('http.unprocessable')
        }
        break

Aqui, estamos adicionando um tratamento adicional para o erro 422, estaremos personalizando a notificação para exibir os erros retornados pela API, assim como, emitindo um erro com estes eventos. Não estamos usando o $t para localizar a mensagem, por que a API já está retornando o texto localizado.

Este evento será interceptado pelos componentes, para que eles possam atualizar a UI para exibir o erro da maneira correta.

    if (status === 401) {
      store.commit('app/token', undefined)
      router.push('/login')
    }

E caso a aplicação retorne um 401, possivelmente houve a tentativa de acessar um recurso protegido usando um token invalido, note que, uma falha na autorização resultaria em um error 403

E como estamos regionalizando as mensagens de erro, precisamos incluir os devidos textos os arquivos de internacionalização.

Quasar.App/src/i18n/en-us/index.js

export default {
  http: {
    generic: 'Something not right happened',
    badRequest: 'We aren\'t able of to do your request, please review all the fields',
    unauthorized: 'You aren\'t authorized, please login',
    forbidden: 'You aren\'t allowed to do that action',
    unprocessable: '@:http.badRequest',
    serverError: 'An unexpected error occurred at the API',
    serviceUnavailable: 'An error occurred at the API, mostly because a third party service'
  }
}

Quasar.App/src/i18n/pt-br/index.js

export default {
  http: {
    generic: 'Algo de errado aconteceu',
    badRequest: 'Não foi possivel realizar esta ação, por favor revise os campos',
    unauthorized: 'Você não está logado',
    forbidden: 'Você não está autorizado a realizar esta ação',
    unprocessable: '@:http.badRequest',
    serverError: 'Ocorreu um erro inesperado na API',
    serviceUnavailable: 'Ocorreu um erro na API, possivelmente ao tentar acessar um serviço externo'
  }
}

QPANC - Parte 13 - Quasar - Regionalização e Stores

Tobias Mesquita — Sun, 19 Apr 2020 23:38:07 +0000

27 Configuração do i18n

Agora que já configuramos a persistência dos dados relativos ao cliente, podemos configurar os parâmetros de internacionalização.

Para tal, vá até o boot i18n (ele deve ter sido criado durante a criação do projeto, caso não tenha sido, você deverá adiciona-lo agora):

QPANC.App/src/boot/i18n.js

import Vue from 'vue'
import VueI18n from 'vue-i18n'
import messages from 'src/i18n'
import { Quasar } from 'quasar'

Vue.use(VueI18n)

export default ({ Vue, app, store }) => {
  const fallback = Quasar.lang.isoName
  const locale = store.getters['app/locale'] || fallback
  Quasar.lang.set(locale)
  const i18n = new VueI18n({
    locale: locale,
    fallbackLocale: fallback,
    messages
  })

  app.i18n = i18n
}

28 Troca de Idioma

Para alternar entre um idioma e outro, é bem simples, basta seta o idioma desejado no i18n e no lang do quasar. iremos construir um componente bem simples, que irá permitir que o usuário escolha o idioma desejado.

Como primeiro passo, iremos adicionar à pasta statics alguns ícones, no caso a bandeira do Brasil e a dos Estados Unidos. você pode conseguir estes arquivos no site Flat Icon

Então crie a pasta locale em QPANC.App/src/components e adicione os arquivos index.js, index.vue e index.sass

QPANC.App/src/components/locale/index.js

export default {
  name: 'LocaleComponent',
  data () {
    return {
      fab: false
    }
  },
  computed: {
    locale () {
      return this.$store.getters['app/locale']
    },
    icon () {
      return `img:statics/flags/${this.locale}.svg`
    }
  },
  methods: {
    async set (locale) {
      this.$store.commit('app/localeUser', locale)
      this.$i18n.locale = locale
      const lang = await import('quasar/lang/' + locale)
      this.$q.lang.set(lang)
    }
  }
}

QPANC.App/src/components/locale/index.sass

.component-locale
  .q-btn--fab .q-btn__wrapper
    padding: 0
    .q-fab__icon-holder,
    img
      width: 56px
      height: 56px
  .q-btn--fab-mini .q-btn__wrapper
    padding: 0
    img
      width: 40px
      height: 40px

QPANC.App/src/components/locale/index.vue

<template>
  <q-page-sticky position="bottom-right" class="component-locale" :offset="[18, 18]">
    <q-fab v-model="fab" :label="$t('locale.title')" external-label vertical-actions-align="right" :icon="icon" direction="up" >
      <q-fab-action label-position="left" icon="img:statics/flags/pt-br.svg" @click="set('pt-br')" :label="$t('locale.ptbr')" external-label />
      <q-fab-action label-position="left" icon="img:statics/flags/en-us.svg" @click="set('en-us')" :label="$t('locale.enus')" external-label />
    </q-fab>
  </q-page-sticky>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

A troca de idioma é realizada no seguinte trecho de código:

    async set (locale) {
      this.$store.commit('app/localeUser', locale)
      this.$i18n.locale = locale
      const lang = await import('quasar/lang/' + locale)
      this.$q.lang.set(lang)
    }

Como você deve ter percebido, este componente usa alguns textos localizados, então precisamos atualizar os arquivos JSON utilizados pelo i18n.

Quasar.App/src/i18n/en-us/index.js

export default {
  locale: {
    title: 'Idiom',
    ptbr: 'Portuguese',
    enus: 'English'
  }
}

Quasar.App/src/i18n/pt-br/index.js

export default {
  locale: {
    title: 'Idioma',
    ptbr: 'Português',
    enus: 'Inglês'
  }
}

Agora precisamos registrar este componente, para tal, crie o boot components

quasar new boot components

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    boots: [
      'components'
    ]
  }
}

QPANC.App/src/boot/components.js

import Vue from 'vue'

Vue.component('locale-switch', () => import('components/locale/index.vue'))

E por fim, adicione este componente aos layouts main e clean

<template>
  <q-layout id="layout-clean" view="lHh Lpr lFf" class="bg-main">
    <!-- ... -->
    <locale-switch></locale-switch>
  </q-layout>
</template>

E então podemos executar a aplicação e realizar alguns testes. Como sugestão, abra a tela de Login, envie um usuário/senha incorretos, troque o idioma e tente novamente. A aplicação deverá alternar entre os dois idiomas, assim como a API deve retornar os erros no mesmo idioma que a aplicação.

29 Injetando o Global bus, i18n e router na store

Em uma aplicação SSR, como devemos manter o isolamento os serviços e recursos, não podemos exportar e consequentemente importar recursos de forma global.

Porém, é comum que precisemos acessar as rotas, os textos localizados, ou até mesmo emitir e escutar eventos.

Neste caso, podemos criar um arquivo de boot, e injetar estes recursos direto na store.:

quasar new boot store

E claro, não esqueça de adicionar ele ao quasar.config.js > boots. Apenas lembre-se que este boot deve ser colocado após o i18n.

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    boots: [
      'i18n',
      'store'
    ]
  }
}

E agora, a implementação deste boot.:

QPANC.App/src/boot/store.js

export default async ({ app, store, router }) => {
  store.$router = router
  Object.defineProperty(store, '$t', {
    get () {
      return app.i18n.t.bind(app.i18n)
    }
  })
  Object.defineProperty(store, '$route', {
    get () {
      return router.route
    }
  })
  Object.defineProperty(store, '$root', {
    get () {
      return router.app.$root
    }
  })
}

A partir deste ponto, você pode acessar o this.$root, this.$t, this.$router e this.$route de suas actions, mutations e getters.

QPANC - Parte 12 - Quasar - Serviços

Tobias Mesquita — Sun, 19 Apr 2020 23:38:06 +0000

24 Injetar objetos nos componentes, stores e routes.

Para o correto funcionamento de uma aplicação SSR, alguns serviços precisam ser instanciados de maneira isolada, de forma, que um usuário não consiga acessar a uma instancia destinada a outro usuário, em resumo, todos os serviços devem está preferencialmente isoladas dentro do escopo do usuário.

O primeiro passo para conseguir este objetivo, é criar um utilitário que irá injetar estes serviços nos components, store e routes.

QPANC.App/src/boot/inject.js

import Vue from 'vue'

const mixins = []
const inject = function (bootCb) {
  return async function (ctx) {
    const { app, router, store } = ctx
    let boot
    if (typeof bootCb === 'function') {
      const response = bootCb(ctx)
      boot = response.then ? await response : response
    } else {
      boot = bootCb
    }

    for (const name in boot) {
      const key = `$${name}`
      if (mixins.indexOf(name) === -1) {
        mixins.push(name)
        Vue.mixin({
          beforeCreate () {
            const options = this.$options
            if (options[name]) {
              this[key] = options[name]
            } else if (options.parent) {
              this[key] = options.parent[key]
            }
          }
        })
      }
      app[name] = boot[name]
      store[key] = boot[name]
      router[key] = boot[name]
    }
  }
}

export default inject

Agora, um exemplo de utilização.:

Digamos que tenhamos um serviço que faz o print da mensagem Hello World no console.:

class DummieService {
  sayHello ({ name }) {
    console.log(`${name}: Hello Wolrd`)
  }
}

E agora queremos injetar uma instancia do serviço acima em todos os componentes, stores e routes, poderemos faze-lo em um arquivo de boot.

import inject from './inject'
import DummieService from 'services/dummie'

export default inject(({ Vue }) => {
  const dummie = new DummieService()
  return {
    dummie: dummie
  }
})

feito isto, poderemos acessar this.$dummie nos componentes e stores, assim como router.$dummie nos navigation guards, segue alguns exemplos.:

sample/page/dummie.js

export default {
  data () {
    const initialMsg = this.$dummie.sayHello({ name: 'me' })
    return {
      msg: initialMsg
    }
  },
  methods: {
    changeName ({ name }) {
      this.msg = this.$dummie.sayHello({ name })
    }
  }
}

sample/store/dummie.js

export default {
  namespaed: true,
  state () {
    return {
      name: 'me',
      msg: ''
    }
  },
  mutations: {
    name (state, value) { state.name = value },
    msg (state, value) { state.msg = value }
  },
  actions: {
    setMessage ({ commit }, name) {
      const msg = this.$dummie.sayHello({ name })
      commit('msg', msg)
    }
  },
  getters: {
    getMessage (state) {
      return this.$dummie.sayHello({ name: state.name })
    }
  }
}

sample/router/dummie.js

export default function (context) {
  return {
    path: '/dummie',
    beforeEnter (to, from, next) {
      const { $dummie } = context.router
      const msg = $dummie.sayHello({ name: to.params.name })
      if (msg.length > 50) {
        next('/hello-long-name')
      } else {
        next('/hello-short-name')
      }
    }
  }
}

25 Customizando os componentes do Quasar

Para esta tarefa, estarei usando a extensão @toby-mosque/utils, porém não irei mostrar um código equivalente sem o uso da extensão, pois envolve um transparent wrapper bem intricado, onde um pequeno deslize, pode levar a um bug difícil de rastrear ou a um comportamento indesejado.

Para esta demostração, estaremos personalizando apenas o QInput, mas podemos customizar qual quer componente, inclusive aqueles que são instalados através de extensões.

O primeiro passo, é criar um boot, aqui chamaremos ele de brand

quasar new boot brand

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    boots: [
      'brand'
    ]
  }
}

QPANC.App/src/boot/inject.js

import { factory } from '@toby.mosque/utils'
import inject from './inject'
import { QInput } from 'quasar'

// "async" is optional
export default inject(({ Vue }) => {
  const brand = {}
  brand.input = Vue.observable({
    /*
    style: {
      'font-size': '12px'
    },
    class: {
      'custom-input': true
    },
    */
    props: {
      outlined: true
    }
  })

  factory.reBrand('q-input', QInput, brand.input)
  return {
    brand
  }
})

O objeto brand será injetado nos componentes e stores, então poderemos acessa-lo futuramente.

A propriedade input é um Vue.observable, estão qual quer alteração nele, será refletido para os componentes que fazem uso dele. input é apenas um nome, poderia ser qual quer coisa no lugar.

O factory.reBrand, é o responsável por injetar o brand.input em todos os q-input. Ele fará uso apenas das propriedades style, class e props, onde estas propriedades serão injetadas no style, class e props do respectivo componente, sendo que nenhum deles é obrigatório.

Caso execute a aplicação agora, verá que todos os inputs estarão com a propriedade :outlined="true"

Agora, vamos adaptar o exemplo acima, para usar o Dark Mode, onde os inputs deverão ser filled no modo dark e outlined no light

QPANC.App/src/boot/inject.js

import { factory } from '@toby.mosque/utils'
import inject from './inject'
import { QInput, Dark } from 'quasar'

// "async" is optional
export default inject(({ Vue }) => {
  const brand = {}
  brand.input = Vue.observable({
    /*
    style: {
      'font-size': '12px'
    },
    class: {
      'custom-input': true
    },
    */
    props: {
      filled: Dark.isActive
      outlined: !Dark.isActive
    }
  })

  factory.reBrand('q-input', QInput, brand.input)
  return {
    brand
  }
})

O problema aqui, é que o Dark.isActive está sendo usado apenas como o valor inicial para o brand.input, porém quando o Dark.isActive é alterado, ele não é propagado para o brand.input.

Então, precisaremos de um watch no App.vue.

QPANC.App/src/App.vue

export default {
  name: 'App',
  watch: {
    '$q.dark.isActive' () {
      this.$brand.input.props.filled = this.$q.dark.isActive
      this.$brand.input.props.outlined = !this.$q.dark.isActive
    }
  }
}

E por fim, algumas prints.:

25 Persistência em Cookies

Como se trata de uma aplicação SSR, é natural que alguns dados serão persistidos no lado do cliente, coisas como o Token JWT, o tema e o idioma preferido.

Porém, alguns destes dados precisam ser acessados no lado do servidor, e como não podem ser recuperados de outra forma, teremos de usar Cookies.

O primeiro passo, será ativar o plugin responsável por ler os Cookies.

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    framework: 
      plugins: [
        'Cookies'
      ]
    }
  }
}

Agora, iremos adicionar um plugin para o vuex, no caso o vuex-persistedstate

yarn add vuex-persistedstate

Agora, adicione o boot persist, e não deixe e adicionar ele ao quasar.config.js > boots, é vital que ele seja adicionado antes do boot do axios e do i18n.

quasar new boot persist

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    boots: [
      'persist',
      'i18n',
      'axios'
    ]
  }
}

Antes de codificamos o boot persist, precisamos criar um pequeno serviço, que será responsável por detectar o idioma recomendado para o usuário.

QPANC.App/src/services/locales.js

const locales = ['en-us', 'pt-br']
const regions = {
  en: 'en-us',
  pt: 'pt-br'
}
const fallback = regions.en
const detectLocale = function () {
  if (process.env.CLIENT) {
    const locale = navigator.language.toLowerCase()
    if (locales.includes(locale)) {
      return locale
    }
    const region = locale.split('-')[0]
    if (region in regions) {
      return regions[region]
    }
    return regions.en
  } else {
    return fallback
  }
}

export {
  locales,
  regions,
  fallback,
  detectLocale
}

Agora, vamos ao boot:

QPANC.App/src/boot/persist.js

import { Cookies, Quasar } from 'quasar'
import createPersistedState from 'vuex-persistedstate'

const persistState = function ({ name, store, storage }) {
  createPersistedState({
    key: name,
    paths: [name],
    filter ({ type }) {
      return type.startsWith(name)
    },
    storage
  })(store)
}

export default function ({ store, ssrContext }) {
  const cookies = process.env.SERVER
    ? Cookies.parseSSR(ssrContext)
    : Cookies

  const cookieStorage = {
    getItem (key) {
      return JSON.stringify(cookies.get(key))
    },
    setItem (key, value) {
      cookies.set(key, value, { path: '/' })
    },
    removeItem (key) {
      cookies.remove(key, { path: '/' })
    }
  }

  persistState({ name: 'app', store, storage: cookieStorage })
  if (process.env.CLIENT) {
    // persistState({ name: 'local', store, storage: window.localStorage })
    store.commit('app/localeOs', detectLocale())
  }
}

Um pequeno detalhamento sobre o que está sendo feito:

persistState({ name: 'app', store, storage: cookieStorage })

Estamos instruindo o vuex-persistedstate à persistir todo o modulo app em um Cookie

if (process.env.CLIENT) {
  // persistState({ name: 'local', store, storage: window.localStorage })
}

Caso o comentário seja removido, estamos instruindo o vuex-persistedstate à persistir todo o modulo local no localStorage

if (process.env.CLIENT) {
  store.commit('app/localeOs', detectLocale())
}

Estamos atualizando o localeOs para que ele seja igual ao locale disponível mais próximo ao que é utilizado pelo browser, este vai ser o idioma da aplicação, caso o usuário também não especifique o localeUser.

Porém vale lembrar, que o código no cliente é executado após a execução no servidor, então, na primeira requisição, o servidor irá sempre utilizar a linguagem padrão, no caso, o inglês (isto é configurável em quasar.config.js > framework > lang).

Desta forma, na primeira requisição, o app será carregado usando a linguagem padrão, e irá alternar para a linguagem informada pelo browser após a conclusão do carregamento da pagina.

Agora, vamos criar o nosso modulo app

QPANC.App/src/store/app.js

import { factory } from '@toby.mosque/utils'

class AppStoreModel {
  constructor ({
    token = '',
    localeOs = '',
    localeUser = ''
  } = {}) {
    this.token = token
    this.localeOs = localeOs
    this.localeUser = localeUser
  }
}

const options = {
  model: AppStoreModel
}

export default factory.store({
  options,
  getters: {
    locale (state) {
      return state.localeUser || state.localeOs
    }
  }
})

export { options, AppStoreModel }

Como se trata de um modulo global, não esqueça de registra-lo no QPANC.App/src/store/index.js

QPANC.App/src/store/index.js

import Vue from 'vue'
import Vuex from 'vuex'
import app from './app'

Vue.use(Vuex)

export default function (context) {
  const Store = new Vuex.Store({
    modules: {
      app
    },
    strict: process.env.DEV
  })

  return Store
}

QPANC - Parte 11 - Quasar - Componentes - Diferença entre SPA e SSR

Tobias Mesquita — Sun, 19 Apr 2020 23:38:05 +0000

22 Componente de Login

Iremos utilizar o componente de Login, para demonstrar as diferenças entre um componente feito para um SPA, e um feito para um SSR, que demanda que os dados sejam hidratados.

22.1 - SPA

o nosso primeiro passo, será criar os layouts, por hora iremos usar um layout clean para as atividades de autenticação (landspage, login, registro, etc) e outro para as demais paginas.

Lembrando que esta estrutura é apenas um exemplo, por mais que seja aplicável a maioria dos projetos, não encarre ela como sendo uma bala de prata.

o primeiro componente que iremos fazer, é o layout clean.
Quasar.App/src/layout/clean/index.vue

<template>
  <q-layout id="layout-clean" view="lHh Lpr lFf" class="bg-main">
    <q-page-container>
      <q-page class="row">
        <div class="col flex flex-center relative-position layout-auth">
          <img alt="Quasar logo" class="absolute-center" src="~assets/quasar-logo-full.svg">
        </div>
        <div class="col col-auto shadow-up-2 page-container relative-position bg-content">
          <div class="page-form q-pa-xl absolute-center">
            <router-view />
          </div>
        </div>
      </q-page>
    </q-page-container>
  </q-layout>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

Quasar.App/src/layout/clean/index.js

export default {
  name: 'CleanLayout'
}

Quasar.App/src/layout/clean/index.sass

#layout-clean
  .page-container
    width: 540px !important
    .page-form
      width: 100%
  @media (max-width: $breakpoint-sm-max)
    .page-container
      width: 100% !important

note que estamos usando o id do layout no primeiro nível do arquivo index.sass, isto é necessário para garantir que este estilo será aplicado apenas para este componente e os seus respectivos filhos.

Agora, vamos criar a pagina responsável pelo login em QPANC.App/src/pages/login
QPANC.App/src/pages/login/index.vue

<template>
  <div id="page-login">
    <h5 class="q-my-md">{{$t('login.title')}}</h5>
    <q-separator></q-separator>
    <q-form class="row q-col-gutter-sm">
      <div class="col col-12">
        <q-input v-model="userName" :label="$t('fields.userName')" :rules="validation.userName"></q-input>
      </div>
      <div class="col col-12">
        <q-input type="password" v-model="password" :label="$t('fields.password')" :rules="validation.password"></q-input>
      </div>
      <div class="col col-5">
        <q-btn class="full-width" flat color="primary" :label="$t('actions.forget')" @click="forget"></q-btn>
      </div>
      <div class="col col-12">
        <q-btn class="full-width" color="positive" :label="$t('actions.login')" @click="forget"></q-btn>
      </div>
    </q-form>
  </div>
</template>

<script src="./index.js"></script>
<style src="./index.sass" lang="sass"></style>

QPANC.App/src/pages/login/index.js

import validations from 'services/validations'

export default {
  name: 'LoginPage',
  data () {
    const self = this
    const validation = validations(self, {
      userName: ['required', 'email'],
      password: ['required']
    })
    return {
      userName: '',
      password: '',
      validation
    }
  },
  methods: {
    forget () {
      console.log('forget: not implemented yet')
    },
    login () {
      this.validation.resetServer()
      const isValid = await this.$refs.form.validate()
      if (isValid) {
        console.log('login: not implemented yet')
      }
    }
  }
}

QPANC.App/src/pages/login/index.sass

#page-login

No exemplo acima, o arquivo index.sass não possui nenhum estilo, por tanto ele é dispensável, podendo ser excluído.

Agora, precisamos modificar as nossas rotas em QPANC.App/src/routes

QPANC.App/src/routes/areas/clean.js

export default function (context) {
  return {
    path: '',
    component: () => import('layouts/clean/index.vue'),
    children: [
      { name: 'login', path: 'login', component: () => import('pages/login/index.vue') },
      { name: 'register', path: 'register', component: () => import('pages/register/index.vue') }
    ]
  }
}

QPANC.App/src/routes/routes.js

import clean from './areas/clean'

export default function (context) {
  const routes = [{
    path: '/',
    component: {
      render: h => h('router-view')
    },
    children: [
      {
        path: '/',
        beforeEnter (to, from, next) {
          next('/login')
        }
      },
      clean(context)
    ]
  }]

  // Always leave this as last one
  if (process.env.MODE !== 'ssr') {
    routes.push({
      path: '*',
      component: () => import('pages/Error404.vue')
    })
  }

  return routes
}

QPANC.App/src/routes/routes.js

import Vue from 'vue'
import VueRouter from 'vue-router'
import routes from './routes'

Vue.use(VueRouter)

export default function (context) {
  context.router = new VueRouter({
    scrollBehavior: () => ({ x: 0, y: 0 }),
    routes: routes(context),
    mode: process.env.VUE_ROUTER_MODE,
    base: process.env.VUE_ROUTER_BASE
  })

  return context.router
}

Originalmente, o routes.js retornava as rotas de forma direta, porém precisamos encapsular esta logica dentro de um função, para que possamos passar o contexto. Através do contexto, nós teremos acesso ao objeto router, store e ssrContext, o que nós será bastante útil durante a construção dos navigation guards.

Uma nota quanto ao component: { render: h => h('router-view') }, esta é a forma que temos para definir uma rota no vue-router que será renderizada, porém sem especificar um componente, esta técnica é especialmente útil, quando a intenção é unicamente agrupar as rotas.

Outro aspecto, é que não possuirmos uma rota na raiz da aplicação, por isto é necessário declarar uma rota com beforeEnter que redireciona a aplicação para o /login. Por hora poderíamos utilizar o redirect ou alias, mas futuramente este redirecionamento será condicionado ao fato do usuário está logado ou não. Lembrando que esta roda não será renderizada, por tanto, não é necessário utilizar o component: { render: h => h('router-view') }.

Agora, podemos acessar a aplicação:

22.2 - SSR

Tecnicamente, o Login do jeito que está, já está apto para uma aplicação SSR, uma vez que, ele não faz nenhuma requisição assincronia durante a sua montagem/criação.

Porém, caso o fizesse, seria necessário criar um modulo no vuex dedicado para esta pagina, e mover as propriedades reativas que estão no data para o state deste modulo.

E por fim, fazer o carregamento dos dados no state usando uma action, que seria chamada no preFetch.

Mas mesmo sem precisar, iremos converter a pagina para usar uma store, até para que todas as paginas do sistema venham a ter a mesma estrutura. O primeiro passo, será ativar o recurso do preFetch no quasar.config.js > preFetch:

QPANC.App/quasar.config.js

module.exports = function (ctx) {
  return {
    preFetch: true
  }
}

O segundo passo, é criar uma store dentro da pasta da pagina, ou seja QPANC.App/src/pages/login

QPANC.App/src/pages/login/store.js

export default {
  namespaced: true,
  state () {
    return {
      userName: '',
      password: ''
    }
  },
  mutations: {
    userName (state, value) { state.userName = value },
    password (state, value) { state.password = value }
  },
  actions: {
    async initialize ({ state }, { route, next }) {
    },
    forget ({ state }) {
      console.log('forget: not implemented yet')
    },
    login ({ state }) {
      console.log('login: not implemented yet')
    }
  }
}

Então, precisamos registrar este modulo no index.js, assim como chamar a action initialize no preFetch.

QPANC.App/src/pages/login/index.js

import validations from 'services/validations'
import pageModule from './store'

const moduleName = 'page-login'
export default {
  name: 'LoginPage',
  preFetch ({ store, currentRoute, redirect }) {
    store.registerModule(moduleName, pageModule)
    return store.dispatch(`${moduleName}/initialize`, { route: currentRoute, next: redirect })
  },
  created () {
    if (process.env.CLIENT) {
      this.$store.registerModule(moduleName, pageModule, { preserveState: true })
    }
  },
  destroyed () {
    this.$store.unregisterModule(moduleName)
  },
  data () {
    const self = this
    const validation = validations(self, {
      userName: ['required', 'email'],
      password: ['required']
    })
    return {
      validation
    }
  },
  computed: {
    userName: {
      get () { return this.$store.state[moduleName].userName },
      set (value) { this.$store.commit(`${moduleName}/userName`, value) }
    },
    password: {
      get () { return this.$store.state[moduleName].password },
      set (value) { this.$store.commit(`${moduleName}/password`, value) }
    }
  },
  methods: {
    forget () {
      this.$store.dispatch(`${moduleName}/forget`)
    },
    login () {
      this.$store.dispatch(`${moduleName}/login`)
    }
  }
}

Os hooks preFetch, created e o destroyed são usados para gerenciar o ciclo de vida do modulo do vuex, para que ele tenha um ciclo de vida semelhante ao da pagina.

A action initialize está sendo chamada do preFetch, desta forma a pagina será renderizada apenas quando o preFetch for concluído.

No computed, estamos mapeando o state e os mutations, para que seja possível utilizar o two-way bind (v-model) com o state do vuex.

O methods está servindo apenas de proxy para as actions do modulo dedicado a esta pagina.

E por fim, no data temos apenas campos de controle, utilitários, semi-estáticos, etc. Como por exemplo, o rules ou as definições das colunas de uma tabela.

Caso não deseje usar a extensão sugerida no próximo tópico, recomendo que dê uma olhada no plugin vuex-map-fields.

22.3 - SSR usando `@toby-mosque/utils`

O primeiro passo, é instalar a extensão '@toby.mosque/utils'

quasar ext add '@toby.mosque/utils'

altere o jsconfig.json > compilerOptions > paths para incluir o seguinte item:

QPANC.App/jsconfig.json

{
  "compilerOptions": {
    "paths": {
      "@toby.mosque/utils": [
        "node_modules/@toby.mosque/quasar-app-extension-utils/src/utils.js"
      ]
    }
  }
}

Então, altere o arquivo store.js
QPANC.App/src/pages/login/store.js

import { factory } from '@toby.mosque/utils'

class LoginPageModel {
  constructor ({
    userName = '',
    password = ''
  } = {}) {
    this.userName = userName
    this.password = password
  }
}

const options = {
  model: LoginPageModel
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    },
    forget ({ state }) {
      console.log('forget: not implemented yet')
    },
    login ({ state }) {
      console.log('login: not implemented yet')
    }
  }
})

export { options, LoginPageModel }

Note que as propriedades do state e os respectivos mutations foram movidos para a classe LoginPageModel. A factory factory.store irá criar o state e o mutations usando a classe LoginPageModel como referencia.

Ao usar a factory.store, a action initialize torna-se um requisito, deve ser declarada, mesmo que não faça muito (ou nada).

Note que, apesar do factory.store montar alguns states, mutations, getters e actions, você poderá declarar os seus próprios states, mutations, getters e actions, pois a store gerada pelo factory.store, será o resultado da mesclagem entre ambos.

Agora, modifique o script index.js
QPANC.App/src/pages/login/index.js

import validations from 'services/validations'
import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'page-login'
export default factory.page({
  name: 'LoginPage',
  options,
  moduleName,
  storeModule: store,
  data () {
    const self = this
    const validation = validations(self, {
      userName: ['required', 'email'],
      password: ['required']
    })
    return {
      validation
    }
  },
  methods: {
    forget () {
      this.$store.dispatch(`${moduleName}/forget`)
    },
    login () {
      this.validation.resetServer()
      const isValid = await this.$refs.form.validate()
      if (isValid) {
        this.$store.dispatch(`${moduleName}/login`)
      }
    }
  }
})

Note, que não é mais necessário gerenciar o ciclo de vida do modulo (preFetch, created e destroyed), assim como invocar a action initialize, pois o factory.page irá faze-lo por você.

Outro ponto que já não é necessário, é o mapeamento do state e dos mutations no computed, pois ele também é feito pelo factory.page.

Note que, apesar da factory.page gerá os hooks preFetch, created, destroyed, computed e methods, você poderá definir os seus próprios preFetch, created, destroyed, computed e methods, pois a page gerada pelo factory.page, será o resultado da mesclagem entre ambos

Apenas um detalhe, o options, além do campo model, possui os campos collections e complexTypes. Eles são utilizados para criar/gerenciar um state do tipo Array (collections) ou Object (complexTypes), neste caso, será gerado getters e actions para acessar e manipular estes dados.

Para mais detalhes, leia: Quasar - Utility Belt App Extension to speedup the development of SSR and offline first apps.

22.4 - Considerações

A partir deste monto, estarei utilizando o @toby.mosque/utils para a construção de layouts e pages.

Um outro ponto importante a se citar, é que todos os componentes de layout e page devem ser utilizados no routes.js, assim como, o routes.js só deve declarar componentes provenientes da pasta layouts ou pages.

Isto se faz necessário, pois o hook preFetch existe apenas para os componentes que compõem a rota, pois o preFetch é construído sobre um navigation guard, desta forma, não podemos usar a factory.page para os demais componentes, ou seja, aqueles que iremos criar na pasta components e serão consumidos pelos layouts e pages

23 Exemplos avançados com a extensão `@toby-mosque/utils`

23.1 - Coleções

O primeiro exemplo, é sobre a geração de uma store que possua um Array, neste caso, iremos configurar o options collections.

models/item.js

export default class ItemModel {
  constructor ({
    id = 0,
    fieldA = '',
    fieldB = ''
  } = {}) {
    this.id = id,
    this.fieldA = fieldA
    this.fieldB = fieldB
  }
}

sample/store.js

import { factory } from '@toby.mosque/utils'
import ItemModel from 'models/item'

class SampleModel {
  constructor ({
    collectionA = [],
    collectionB = []
  } = {}) {
    this.collectionA = collectionA
    this.collectionB = collectionB
  }
}

const options = {
  model: SampleModel,
  collections: [
    { single: 'itemA', plural: 'collectionA', id: 'id', type: ItemModel },
    { single: 'itemB', plural: 'collectionB', id: 'id', type: ItemModel }
  ]
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    }
  }
})

export { options, LoginPageModel }

então, a partir do options, a factory.store será capaz de criar a seguinte store.:

sample/store_generated.js

import Vue from 'vue'

export default {
  namespaced: true,
  state () {
    return {
      collectionA = [],
      collectionB = []
    }
  },
  mutations: {
    collectionA (state, value) { Vue.set(state, 'collectionA', value) },
    collectionB (state, value) { Vue.set(state, 'collectionB', value) },
    createItemA (state, item) { state.collectionA.push(item) },
    updateItemA (state, { index, item }) { Vue.set(state.collectionA, index, item) },
    deleteItemA (state, index) { Vue.delete(state.collectionA, index) },
    createItemB (state, item) { state.collectionB.push(item) },
    updateItemB (state, { index, item }) { Vue.set(state.collectionB, index, item) },
    deleteItemB (state, index) { Vue.delete(state.collectionB, index) }
    setFieldAOfAnItemA  (state, { index, value }) { Vue.set(state.collectionA[index], 'fieldA', item) }
    setFieldBOfAnItemA  (state, { index, value }) { Vue.set(state.collectionA[index], 'fieldB', item) }
    setFieldAOfAnItemB  (state, { index, value }) { Vue.set(state.collectionB[index], 'fieldA', item) }
    setFieldBOfAnItemB  (state, { index, value }) { Vue.set(state.collectionB[index], 'fieldB', item) }
  },
  actions: {
    async initialize ({ state }, { route, next }) {
    },
    saveOrUpdateItemA ({ commit, getters }, item) {
      const index = getters.collectionAIndex.get(item.id)
      if (index !== undefined) {
        commit('updateItemA', { index, item })
      } else {
        commit('createItemA', item)
      }
    },
    deleteItemA ({ commit, getters }, id) {
      const index = getters.collectionAIndex.get(id)
      if (index !== undefined) {
        commit('deleteItemA', index)
      }
    },
    saveOrUpdateItemB ({ commit, getters }, item) {
      const index = getters.collectionBIndex.get(item.id)
      if (index !== undefined) {
        commit('updateItemB', { index, item })
      } else {
        commit('createItemB', item)
      }
    },
    deleteItemB ({ commit, getters }, id) {
      const index = getters.collectionBIndex.get(id)
      if (index !== undefined) {
        commit('deleteItemB', index)
      }
    },
    setFieldAOfAnItemA ({ commit, getters }, { id, value }) {
      const index = getters.collectionAIndex.get(id)
      if (index !== undefined) {
        commit('setFieldAOfAnItemA', { index, value })
      }
    },
    setFieldBOfAnItemA ({ commit, getters }, { id, value }) {
      const index = getters.collectionAIndex.get(id)
      if (index !== undefined) {
        commit('setFieldBOfAnItemA', { index, value })
      }
    },
    setFieldAOfAnItemB ({ commit, getters }, { id, value }) {
      const index = getters.collectionBIndex.get(id)
      if (index !== undefined) {
        commit('setFieldAOfAnItemB', { index, value })
      }
    },
    setFieldBOfAnItemB ({ commit, getters }, { id, value }) {
      const index = getters.collectionBIndex.get(id)
      if (index !== undefined) {
        commit('setFieldBOfAnItemB', { index, value })
      }
    }
  },
  getters: {
    collectionAIndex (state) {
      return state.collectionA.reduce((map, item, index) => {
        map.set(item.id, index)
        return map
      }, new Map())
    },
    itemAById (state, getters) {
      return function itemAById(id) {
        const index = getters.collectionAIndex.get(id)
        if (index !== undefined) {
          return state.collectionA[index]
        }
      }
    },
    collectionBIndex (state) {
      return state.collectionB.reduce((map, item, index) => {
        map.set(item.id, index)
        return map
      }, new Map())
    },
    itemBById (state, getters) {
      return function itemBById(id) {
        const index = getters.collectionBIndex.get(id)
        if (index !== undefined) {
          return state.collectionB[index]
        }
      }
    }
  }
}

Note que, o prefiro das actions pode ser configurado, o default é saveOrUpdate e delete, mas por exemplo, você pode alterar para upsert e remove.

Agora vamos a page.:

sample/index.js

import ItemASection from 'components/item-a-section/index.vue'
import ItemBSection from 'components/item-b-section/index.vue'
import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'page-sample'
export default factory.page({
  name: 'SamplePage',
  options,
  moduleName,
  storeModule: store,
  data () {
    return {
      moduleName
    }
  },
  components: {
    'item-a-section': ItemASection,
    'item-b-section': ItemBSection
  }
})

A page resultante será a seguinte.:
sample/index_generated.js

import ItemASection from 'components/item-a-section/index.vue'
import ItemBSection from 'components/item-b-section/index.vue'
import store from './store'

const moduleName = 'page-sample'
export default {
  name: 'SamplePage',
  preFetch ({ store, currentRoute, redirect }) {
    store.registerModule(moduleName, pageModule)
    return store.dispatch(`${moduleName}/initialize`, { route: currentRoute, next: redirect })
  },
  created () {
    if (process.env.CLIENT) {
      this.$store.registerModule(moduleName, pageModule, { preserveState: true })
    }
  },
  destroyed () {
    this.$store.unregisterModule(moduleName)
  },
  data () {
    return {
      moduleName
    }
  },
  components: {
    'item-a-section': ItemASection,
    'item-b-section': ItemBSection
  },
  computed: {
    collectionA: {
      get () { return this.$store.state[moduleName].collectionA},
      set (value) { this.$store.commit(`${moduleName}/collectionA`, value) }
    },
    collectionB: {
      get () { return this.$store.state[moduleName].collectionB },
      set (value) { this.$store.commit(`${moduleName}/collectionB`, value) }
    },
    itemAById () {
      return this.$store.getters[`${moduleName}/itemAById`]
    },
    itemBById () {
      return this.$store.getters[`${moduleName}/itemBById`]
    },
    collectionAIndex () {
      return this.$store.getters[`${moduleName}/collectionAIndex`]
    },
    collectionBIndex () {
      return this.$store.getters[`${moduleName}/collectionBIndex`]
    },
  },
  methods: {
    saveOrUpdateItemA (item) {
      return this.$store.dispatch(`${moduleName}/saveOrUpdateItemA`, item)
    },
    deleteItemA (id) {
      return this.$store.dispatch(`${moduleName}/deleteItemA`, id)
    },
    saveOrUpdateItemB (item) {
      return this.$store.dispatch(`${moduleName}/saveOrUpdateItemB`, item)
    },
    deleteItemB (id) {
      return this.$store.dispatch(`${moduleName}/deleteItemB`, id)
    }
  }
}

E para ilustrar, um template.:

sample/index.vue

<template>
  <div>
    <q-card v-for="itemA in collectionA" :key="itemA.id">
      <item-a-section :module="moduleName" :id="itemA.id"></item-a-section>
      <q-card-actions>
        <q-btn icon="delete" @click="deleteItemA(itemA.id)" />
      </q-card-actions>
    </q-card>
    <q-card v-for="itemB in collectionB" :key="itemB.id">
      <item-b-section :module="moduleName" :id="itemB.id"></item-b-section>
      <q-card-actions>
        <q-btn icon="delete" @click="deleteItemA(itemB.id)" />
      </q-card-actions>
    </q-card>
  </div>
</template>

Antes que me pergunte, as actions/mutations com formato semelhante à setFieldBOfAnItemA foram feitas para serem utilizadas em componentes, no exemplo acima, o item-a-section e item-b-section.

Aqui a implementação do item-a-section:

components/item-a-section/index.js

import { store } from '@toby.mosque/utils'
import ItemModel from 'models/item'

const module = store.mapCollectionItemState('', { id: 'id', single: 'itemA', type: ItemModel })

export default {
  name: 'ItemAComponent',
  props: {
    uid: String,
    module: String
  },
  created () {
    module.setModuleName(this.module)
  },
  computed: {
    ...module.computed
  }
}

e por fim o template para este componente:

components/item-a-section/index.vue

<q-card-section>
  <div class="row q-col-gutter-sm">
    <q-input class="col col-12" v-model="fieldA" label="Field A" />
    <q-input class="col col-12" v-model="fieldB" label="Field B" />
  </div>
</q-card-section>

E para ilustrar, o mesmo componente, mas sem o uso do mapCollectionItemState.

components/item-a-section/index_generated.js

export default {
  name: 'ItemAComponent',
  props: {
    uid: String,
    module: String
  },
  created () {
    module.setModuleName(this.module)
  },
  computed: {
    itemAById () {
      return this.$store.getters[`${this.module}/itemAById`]
    },
    itemA () {
      return this.itemAById(this.id)
    },
    fieldA: {
      get () { return this.itemA.fieldA },
      set (value) { 
        this.$store.dispatch(`${this.module}/setFieldAOfAnItemA`, {
          id: this.id,
          value
        })
      }
    },
    fieldA: {
      get () { return this.itemA.fieldB },
      set (value) { 
        this.$store.dispatch(`${this.module}/setFieldBOfAnItemA`, {
          id: this.id,
          value
        })
      }
    }
  }
}

23.2 Tipos Complexos

Ao utilizar o @toby-mosque/utils, o ideal é utilizar objetos com apenas tipos concretos (String, Number, Date) e Array, porém as vezes precisamos utilizar tipos complexos.

sample/store.js

import { factory } from '@toby.mosque/utils'
import ItemModel from 'models/item'

class SampleModel {
  constructor ({
    itemA = new ItemModel(),
    itemB = new ItemModel()
  } = {}) {
    this.itemA = itemA
    this.itemB = itemB
  }
}

const options = {
  model: SampleModel,
  complexTypes: [
    { name: 'itemA', type: ItemModel },
    { name: 'itemB', type: ItemModel }
  ]
}

export default factory.store({
  options,
  actions: {
    async initialize ({ state }, { route, next }) {
    }
  }
})

export { options, LoginPageModel }

esta seria a store gerada pela factory.store:
sample/store.js

export default {
  options,
  state () {
    return {
      itemA: {
        id: 0,
        fieldA: '',
        fieldB: ''
      },
      itemB: {
        id: 0,
        fieldA: '',
        fieldB: ''
      }
    }
  },
  mutations: {
    itemA (state, value) { Vue.set(state, 'itemA', value) },
    itemB (state, value) { Vue.set(state, 'itemB', value) },
    setIdOfItemA (state, value) { state.itemA.id = value },
    setFieldAOfItemA (state, value) { state.itemA.fieldA = value },
    setFieldBOfItemA (state, value) { state.itemA.fieldB = value },
    setIdOfItemB (state, value) { state.itemB.id = value },
    setFieldAOfItemB (state, value) { state.itemB.fieldA = value },
    setFieldBOfItemB (state, value) { state.itemB.fieldB = value }
  },
  actions: {
    async initialize ({ state }, { route, next }) {
    }
  }
}

export { options, LoginPageModel }

Agora, vejamos a page:

sample/index.js

import { factory } from '@toby.mosque/utils'
import store, { options } from './store'

const moduleName = 'page-sample'
export default factory.page({
  name: 'SamplePage',
  options,
  moduleName,
  storeModule: store
})

E um exemplo de template:
sample/index.vue

<template>
  <div>
    <q-card>
      <q-card-section>
        Item A
      </q-card-section>
      <q-separator />
      <q-card-section>
        <div class="row q-col-gutter-sm">
          <q-input class="col col-12" v-model="fieldAOfItemA" label="Field A" />
          <q-input class="col col-12" v-model="fieldBOfItemA" label="Field B" />
        </div>
      </q-card-section>
    </q-card>
    <q-card>
      <q-card-section>
        Item B
      </q-card-section>
      <q-separator />
      <q-card-section>
        <div class="row q-col-gutter-sm">
          <q-input class="col col-12" v-model="fieldAOfItemB" label="Field A" />
          <q-input class="col col-12" v-model="fieldBOfItemB" label="Field B" />
        </div>
      </q-card-section>
    </q-card>
  </div>
</template>

e para fins de comparação, a mesma page, forem sem uso da factory.page

sample/index_generated.js

const moduleName = 'page-sample'
export default {
  name: 'SamplePage',
  preFetch ({ store, currentRoute, redirect }) {
    store.registerModule(moduleName, pageModule)
    return store.dispatch(`${moduleName}/initialize`, { route: currentRoute, next: redirect })
  },
  created () {
    if (process.env.CLIENT) {
      this.$store.registerModule(moduleName, pageModule, { preserveState: true })
    }
  },
  destroyed () {
    this.$store.unregisterModule(moduleName)
  },
  computed () {
    itemA: {
      get () { return this.$store.state[moduleName].itemA },
      set (value) { this.$store.commit(`${moduleName}/itemA`, value) }
    },
    itemB: {
      get () { return this.$store.state[moduleName].itemA },
      set (value) { this.$store.commit(`${moduleName}/itemA`, value) }
    },
    fieldAOfItemA: {
      get () { return this.itemA.fieldA },
      set (value) { this.$store.commit(`${moduleName}/setFieldAOfItemA`, value) }
    },
    fieldBOfItemA: {
      get () { return this.itemA.fieldB },
      set (value) { this.$store.commit(`${moduleName}/setFieldBOfItemA`, value) }
    },
    fieldAOfItemB: {
      get () { return this.itemB.fieldA },
      set (value) { this.$store.commit(`${moduleName}/setFieldAOfItemB`, value) }
    },
    fieldBOfItemB: {
      get () { return this.itemB.fieldB },
      set (value) { this.$store.commit(`${moduleName}/setFieldBOfItemB`, value) }
    }
  }
})

Quanto a geração e manutenção de stores e pages usando o @toby-mosque/utils, não há muito mais a ser dito.

DEV Community: Quasar Framework Brasil

Protegendo uma aplicação com Refresh Tokens.

Índice

1 - Backend - Conhecendo o Backend

2 - Backend - Endpoint de Login

2.1 - Parâmetros do Login

2.2 - Analisando o Login

2.2.1 - Primeiro Cenário - flow=server e rotation=false

2.2.2 - Segundo Cenario - flow=client e rotation=true

3 - Backend - Endpoint de Refresh

3.1 - Parâmetros do Refresh

3.2 - Analisando o Refresh

3.2.1 - Primeiro Cenário - flow=server e rotation=false

3.2.2 - Segundo Cenário - flow=server e rotation=false

4 - Backend - Endpoint de Logout

5 - Frontend - Entendendo as Vulnerabilidades

6 - Frontend - Protegendo um App SPA

6.1 - Realizando o Refresh

6.2 - Integrando a uma API com flow=server

6.3 - Integrando a uma API com rotation=true

7 - Frontend - Protegendo um App SSR

7.1 - Integrando a uma API com rotation=true

7.2 - Integrando a uma API com rotation=false

7.2.1 - Preparando o Server Side

7.2.2 - Comunicação entre o Server Side e o Client Side

Monorepo - Quasar V2 + NestJS

1 - Introdução

2 - Yarn Monorepo

3 - Backend Project - NestJS

4 - Backend Project - OpenAPI

5 - Preparar o Backend para integra-lo ao Frontend

6 - Projeto do Frontend - Quasar

QPANC - Parte 20 - Docker - Traefik e Publicação

40 Configurando os serviços na VM

QPANC - Parte 19 - Docker - Registro e Build

38 Criando um Container Registry no Azure.

39 Fazendo o Build para produção

QPANC - Parte 18 - Docker - Maquina Virtual Linux

36 Configurando uma VM no Azure

37 Instalando o Docker na VPS.

QPANC - Parte 17 - Quasar - Registro

35 Registrar Usuário.

QPANC - Parte 16 - Quasar - Áreas Protegidas

33 Área Principal/Protegida - Parte I.

34 Área Principal/Protegida - Parte 2.

QPANC - Parte 15 - Quasar - Login

31 - Componente de Login - Part 2

32 Lendo o Token JWT

QPANC - Parte 14 - Quasar - Consumindo a API

30 Axios

QPANC - Parte 13 - Quasar - Regionalização e Stores

27 Configuração do i18n

28 Troca de Idioma

29 Injetando o Global bus, i18n e router na store

QPANC - Parte 12 - Quasar - Serviços

24 Injetar objetos nos componentes, stores e routes.

25 Customizando os componentes do Quasar

25 Persistência em Cookies

QPANC - Parte 11 - Quasar - Componentes - Diferença entre SPA e SSR

22 Componente de Login

22.1 - SPA

22.2 - SSR

22.3 - SSR usando @toby-mosque/utils

22.4 - Considerações

23 Exemplos avançados com a extensão @toby-mosque/utils

23.1 - Coleções

23.2 Tipos Complexos

22.3 - SSR usando `@toby-mosque/utils`

23 Exemplos avançados com a extensão `@toby-mosque/utils`