DEV Community: Filipe Nanclarez

Sign in with Apple no Windows com Flutter

Filipe Nanclarez — Mon, 02 May 2022 21:17:38 +0000

Hoje resolvi encarar um desafio que está me consumindo energia a alguns meses já.

Estou criando um aplicativo multiplataforma, e preciso autenticar meus usuários. Uma forma bem conveniente de fazer isso é através de provedores de autenticação conhecidos, como google, facebook, twitter. Isso é conveniente para o usuário, pois não precisa ficar digitando e-mail e senha e lembrando deles depois.

O problema é que a apple exige que se o aplicativo tiver qualquer provedor de autenticação, então ele também deve ter a opção de autenticar pela apple.

Ok, então é simples, vamos começar pela autenticação da apple. Aí foi onde o problema começou a ficar mais complexo.

O suporte para desktop foi lançado a pouco tempo pelo equipe do flutter. Com isso alguns parceiros começaram a lançar seus pacotes tambem. Um pacote que estava muito promissor era o da Invertase. Eles estão trabalhando no suporte completo para do flutterfire para desktop.

Eu aguardei pois sabia que logo logo eles iriam colocar a mão nesse problema, e foi exatamente o que aconteceu. Mas para minha surpresa, eles pularam a parte mais difícil. Eles fizeram a autenticação funcionar em MacOs mas não em Windows. Segundo eles não é prioridade para eles fazer isso agora.

Isso me fez voltar nesse problema, e resolver isso de uma vez por todas. Depois de pesquisar vários pacotes no pub.dev e não achar nenhum que faça isso (se vc achar me conte por favor), eu resolvi adotar um recurso técnico alternativo.

Resolvi fazer uma página web que faça a autenticação e apenas me retorne o e-mail do usuário. E com isso eu faço o resto que preciso no meu aplicativo. Não é a solução mais elegante do mundo, mas me lembro de uma frase que diz 'antes feito que perfeito'. Melhor fazer o possível agora, e futuramente quando for preciso melhorar esse recurso, estudo novamente uma solução mais elaborada.

Então vamos lá.

Configurando o servidor web

Primeiro de tudo, precisamos de um servidor web funcional. Vou usar o mesmo que criamos no meu artigo sobre couchbase. Primeiro vamos instalar o apache.

sudo yum install nano httpd -y

Com isso se acessarmos o servidor já teremos a página do apache abrindo.

Agora vamos criar uma pagina para fazer a autenticação.

Para manter o foco, vamos usar o WinSCP, e só colocar no servidor os arquivos que precisamos. Então vamos conectar no winSCP.

Depois de conectar, vamos colocar o arquivo index.html dentro da pasta /var/www/html. Ao fazer isso, você deve receber um erro de permissão. Esse diretório só pode ser acessado com usuário com permissões administrativas. Para simplificar, vamos configurar o WinSCP para executar o sudo logo após efetuar o login.

Para isso, vamos alterar a configuração do winSCP com esse comando sudo /usr/libexec/openssh/sftp-server ( lembrando que esse procedimento é específico para o CentOS ).

Agora podemos fazer uma página html simples só para testar o servidor. Vamos criar um arquivo com o seguinte conteúdo e salvar como /var/www/html/index.html

<html>
    teste
</html>

Com isso devemos conseguir ver o seguinte resultado:

Configurando a autenticação no console de desenvolvedor da apple

Agora antes de começarmos o código para a autenticação, vamos criar as configurações necessárias no console de desenvolvedor da apple.

Para isso estou seguindo esse artigo

Então primeiro vamos fazer login no portal de desenvolvedor da Apple..

Nessa página, vamos em Certificates, IDs & Profiles

Na tela abaixo, clique no sinal de mais:

Escolha Services IDs e continue:

Preencha a descrição e o identificador. Anote esse identificador pois vamos usar ele mais pra frente.

Finalize registrando o aplicativo.

Agora vamos criar o certificado para a autenticação.

No menu inicial clique em Keys:

Coloque um nome para a chave, e marque a opção Sign in with Apple e depois clique no botão Configure.

Na tela de configuração, escolha o app ( no meu caso, o app já existia, então estou só fazendo a configuração para um app existente ).

Agora que já terminamos de configurar a chave, vamos seguir na tela que estávamos:

Agora confirme o registro na tela final:

ATENÇÃO!

Nessa tela abaixo, anote o ID da chave, pois vamos usar depois. Aqui nós vamos fazer o download do arquivo, que só pode ser feito uma vez, então ESCOLHA BEM ONDE SALVAR ESSE ARQUIVO.

Embora esteja com a extensão p8 esse é um arquivo de texto. Vamos usar ele na mais à frente.

Depois de baixar o arquivo, pode finalizar no botão Done.

Configurando autenticação no console do Firebase

Agora vamos no console do firebase e dentro de Authentication vamos na aba Sign-in method e depois em Adicionar novo fornecedor.

Escolha apple, e depois vamos adicionar as configurações solicitadas.

Service ID é o Service ID identifier que anotamos antes.

Team ID é o código que aparece no topo do console de desenvolvedor da apple:

ID da chave é o Key ID que apareceu na etapa de download da chave:

E agora a na chave privada, vamos abrir aquele arquivo que baixamos, e copiar o conteúdo inteiro dentro do campo:

Agora copie a url de retorno para a próxima etapa.

Configurando a url de retorno

Volte no console de desenvolvedor da apple, e na aba Identifiers clique no menu App IDs à direita e escolha Services IDs:

Escolha o serviço que criamos, e na tela de detalhes escolha o botão Configure:

Escolha o seu app no combo Primary App ID e preencha seu domínio e a url de retorno que acabamos de copiar do console do firebase:

Com isso podemos voltar para o código para fazer a autenticação.

Authenticando com apple via firebase com javascript

Como o que queremos é apenas uma página que será chamada dentro de um webview, não iremos instalar o sdk via npm, nem fazer nenhuma configuração mais elaborada. Vamos apenas chamar os pacotes do firebase diretamente no nosso script e disparar o fluxo de autenticação.

Mas vamos precisar tomar cuidado, para não expor os dados da nosso projeto do firebase no nosso script, pois essa página será pública então vamos encapsular isso usando funções.

Seguindo a documentação do firebase, para importar os pacotes vamos usar o seguinte código:

    // Import the functions you need from the SDKs you need
    import { initializeApp } from "https://www.gstatic.com/firebasejs/9.7.0/firebase-app.js";
    import { getAnalytics } from "https://www.gstatic.com/firebasejs/9.7.0/firebase-analytics.js";

    // TODO: Add SDKs for Firebase products that you want to use
    // https://firebase.google.com/docs/web/setup#available-libraries
    import { OAuthProvider, getAuth, signInWithRedirect, getRedirectResult, signOut  } from 'https://www.gstatic.com/firebasejs/9.7.0/firebase-auth.js';

Depois disso, precisamos inicializar o firebase com as variáveis do nosso projeto. Vamos criar uma função e passar essas variáveis como parâmetros, assim elas não ficam expostas. Como o import dos pacotes só pode ser feito dentro de módulos, e funções dentro de módulos não ficam disponíveis para acesso externo, vamos expor a função jogando ela dentro da variável global window.

Dentro da nossa função, passamos os parâmetros para uma variável, e depois chamamos a inicialização do firebase:

window.initApp = function initApp(apiKey,authDomain,databaseURL,projectId,storageBucket,messagingSenderId,appId,measurementId){
    //Your web app's Firebase configuration
    // For Firebase JS SDK v7.20.0 and later, measurementId is optional
    const firebaseConfig = {
        apiKey: apiKey,
        authDomain: authDomain,
        databaseURL: databaseURL,
        projectId: projectId,
        storageBucket: storageBucket,
        messagingSenderId: messagingSenderId,
        appId: appId,
        measurementId: measurementId
    };

    const app = initializeApp(firebaseConfig);
    const analytics = getAnalytics(app);    
}

Agora que já temos o firebase inicializado, vamos disparar o fluxo de autenticação. Para isso também vamos criar uma função para podemos disparar manualmente em nosso aplicativo flutter.

// Start redirect auth flow
window.sign = async function (){
    let signOutResult = await signOut(auth);
    console.log('sign-out result:');
    console.log(signOutResult);

    // start auth with redirect
    signInWithRedirect(auth, provider);
}

Isso vai fazer a página abrir a tela de autenticação da apple. Depois que o usuário se autenticar, o fluxo vai chamar novamente nossa página. Mas agora, vamos precisar pegar o resultado da autenticação. Então para isso vamos criar outra função, que vai pegar essas informações recebidas após o fluxo de autenticação retornar.

Para enviar uma informação do nosso código javascript para o aplicativo, vamos usar esse código:

window.chrome.webview.postMessage({chave:valor})

Depois veremos como receber isso do lado do flutter.

Então nossa função para receber o retorno do fluxo de autenticação ficou assim:

// Get result from redirect auth flow
window.getResult = function (){
    getRedirectResult(auth) 
    .then((result) => {

        if (!result) return;

        window.chrome.webview.postMessage({"result":JSON.stringify(result)});

    })
    .catch((error) => {
        console.log('erro');
        console.log(error);
        window.chrome.webview.postMessage({"erro ao capturar credencial":JSON.stringify(error)});

    });

}

Adicionando algumas variáveis de controle, um detalhe aqui outro ali, temos o código completo abaixo:

<html>
    <body>
        <div></div>
        <script type="module">
            let auth, provider;

            // Import the functions you need from the SDKs you need
            import { initializeApp } from "https://www.gstatic.com/firebasejs/9.7.0/firebase-app.js";
            import { getAnalytics } from "https://www.gstatic.com/firebasejs/9.7.0/firebase-analytics.js";

            // TODO: Add SDKs for Firebase products that you want to use
            // https://firebase.google.com/docs/web/setup#available-libraries
            import { OAuthProvider, getAuth, signInWithRedirect, getRedirectResult, signOut  } from 'https://www.gstatic.com/firebasejs/9.7.0/firebase-auth.js';

            // Initialize Firebase
            window.initApp = function initApp(apiKey,authDomain,databaseURL,projectId,storageBucket,messagingSenderId,appId,measurementId){
                //Your web app's Firebase configuration
                // For Firebase JS SDK v7.20.0 and later, measurementId is optional
                const firebaseConfig = {
                    apiKey: apiKey,
                    authDomain: authDomain,
                    databaseURL: databaseURL,
                    projectId: projectId,
                    storageBucket: storageBucket,
                    messagingSenderId: messagingSenderId,
                    appId: appId,
                    measurementId: measurementId
                };

                const app = initializeApp(firebaseConfig);
                const analytics = getAnalytics(app);

                provider = new OAuthProvider('apple.com');
                auth = getAuth();

                console.log('firebase init successfully');
            }

            // Start redirect auth flow
            window.sign = async function (){
                let signOutResult = await signOut(auth);
                console.log('sign-out result:');
                console.log(signOutResult);

                // start auth with redirect
                signInWithRedirect(auth, provider);
            }

            // Get result from redirect auth flow
            window.getResult = function (){
                getRedirectResult(auth) 
                .then((result) => {

                    if (!result) return;

                    window.chrome.webview.postMessage({"result":JSON.stringify(result)});

                })
                .catch((error) => {
                    console.log('erro');
                    console.log(error);
                    window.chrome.webview.postMessage({"erro ao capturar credencial":JSON.stringify(error)});

                });

            }
        </script>
    </body>
</html>

Interagindo com o webview no flutter

Agora vamos para o lado 'dart' da força. kkk

Trocadilhos a parte, vamos iniciar um novo projeto flutter, e vamos adicionar o plugin webview_windows e depois abrir ele no Visual Studio Code.

flutter create --platforms=windows auth_apple_no_windows
cd auth_apple_no_windows
flutter pub add webview_windows
code .

Agora vamos:

remover todos os comentários
remover a função de incremento que veio no exemplo padrão
remover o float button
declarar um controller para nosso webview

final _controller = WebviewController();

incluir o webview no corpo da nossa tela:

      body: Webview(
        _controller,
        permissionRequested: _onPermissionRequested,
      ),

O código deverá ficar assim então:

import 'package:flutter/material.dart';
import 'package:webview_windows/webview_windows.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final _controller = WebviewController();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Webview(
        _controller,
      ),
    );
  }
}

Agora precisamos fazer o webview carregar nossa página assim que essa tela for carregada. Para isso vamos usar uma função de retorno que é chamada quando o último frame da tela é desenhado, também conhecida como addPostFrameCallback. Vamos adicionar a chamada dessa função de retorno no método initState do ciclo de vida da tela:

  ...
  final _controller = WebviewController();

  @override
  void initState() {
    super.initState();

    WidgetsBinding.instance?.addPostFrameCallback((_) {
      // do something

    });
  }
  ...

Agora dentro dessa função, vamos inicializar o controlador e pedir para o webview carregar a página que criamos. :

    WidgetsBinding.instance?.addPostFrameCallback((_) async {
      await _controller.initialize();
      await _controller
          .loadUrl('http://example.com');
      if (!mounted) return;
      setState(() {});
    });

Se você tentar rodar o aplicativo nesse momento verá apenas uma tela em branco. Isso porque não disparamos aquelas funções que criamos no javascript.

Então vamos fazer isso através do método executeScript. Mas só podemos fazer isso, depois que a página já estiver totalmente carregada. Para isso, vamos adicionar um 'ouvinte', que vai ficar monitorando o webview e vai nos avisar a cada mudança que ocorrer nele. A mudança que nos interessa é a LoadingState.navigationCompleted.

Nessa situação, vamos chamar a função initApp() passando os parâmetros para iniciar o firebase:

      _controller.loadingState.listen((event) async {
        if (event == LoadingState.navigationCompleted) {
          // inicializando o firebase
          await _controller.executeScript('''
          initApp(
              "AIzaSXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXMA",
              "XXXXXXXXXXX.firebaseapp.com",
              "https://XXXXXXXXX.firebaseio.com",
              "XXXXXXXXXX",
              "XXXXXXXX.appspot.com",
              "96XXXXXXXX19",
              "1:96XXXXXXXXXX19:web:f9XXXXXXXXXXa30XXXXXX6",
              "G-EXXXXXXXX3"
          );
          ''');
        }
      });

Agora que já temos o firebase inicializado, podemos chamar a função que criamos que dispara o login. Podemos fazer isso logo após a inicialização. Não se preocupe, vou postar o código inteiro no final para ficar claro onde exatamente esses pedaços de código estão.

await controller.executeScript('sign();');

Com isso ao executar o aplicativo já irá aparecer a tela de autenticação:

Mas se vc tentar autenticar agora, encontrará um problema. Como estamos disparando a autenticação assim que a página é carregada, após o fluxo de autenticação terminar e o sistema do firebase redirecionar a página de volta para nós, nosso sistema vai disparar novamente a função de autenticação gerando um loop infinito.

Para resolver isso de forma simples, vamos criar uma variável de controle que inicia com valor true. Depois de rodarmos a primeira vez mudamos ela para false e verificamos ela ao disparar a função de autenticação:

var firstRun = true;
...
if (firstRun) {
  firstRun = false;
  await _controller.executeScript('sign();');
}

Agora o que precisamos é capturar o retorno do fluxo de autenticação quando o usuário terminar de fazer login. Como isso só acontece na segunda vez que a página é carregada, vamos usar esse mesmo if e chamar a função que captura o resultado no else:

var firstRun = true;
...
if (firstRun) {
  firstRun = false;
  await _controller.executeScript('sign();');
}else{
  await controller.executeScript('getResult();');
}

E para receber o valor que essa função envia para nós, vamos usar outro 'ouvinte' que vai ficar monitorando todas as mensagens que recebermos do webview. Lembra que eu disse que ia mostrar como recebemos no dart a mensagem que enviamos lá no código javascript? É aqui que isso acontece:

_controller.webMessage.listen((event) async {
  if (event['result'] != null) {
    var userData = json.decode(event['result'])['user'];

    debugPrint(userData['uid']);
    debugPrint(userData['email']);
  }
});

E finalmente o resultado tão esperado. Recebemos o id do usuário lá do firebase, e também o endereço de e-mail dele:

Agora é só usar esses dados da forma que for melhor para o seu projeto.

Talvez você esteja se perguntando como fica a parte de controle da sessão do usuário e logout e onde vai guardar isso. Isso tudo não faz parte do escopo desse artigo. Eu tentei capturar as credenciais e colocar elas dentro de um objeto de autenticação do lado do aplicativo com o método reauthenticateWithCredential conforme essa documentação. Mas o package flutter_desktop_webview_auth da invertase entrou em conflito com o package webview_windows então eu decidi apenas usar os dados do usuário e fazer o meu próprio controle manualmente mesmo.

O pessoal da back4app me sugeriu uma solução parecida com essa que abordamos nesse artigo, mas em vez de usar uma página com javascript, eles indicaram usar o recurso Cloud Functions da plataforma deles.

Vou finalizar deixando o código dart completo conforme prometi.

Até a próxima 😉

import 'dart:convert';

import 'package:flutter/material.dart';
import 'package:webview_windows/webview_windows.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key, required this.title}) : super(key: key);

  final String title;

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final _controller = WebviewController();
  var firstRun = true;

  @override
  void initState() {
    super.initState();

    WidgetsBinding.instance?.addPostFrameCallback((_) async {
      await _controller.initialize();

      _controller.loadingState.listen((event) async {
        if (event == LoadingState.navigationCompleted) {
          // inicializando o firebase
          await _controller.executeScript('''
          initApp(
              "AIXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXmMA",
              "XXXXXXX.firebaseapp.com",
              "https://XXXXXXX.firebaseio.com",
              "XXXXXXX",
              "XXXXXXX.appspot.com",
              "96XXXXXXX19",
              "1:96XXXXXXX19:web:f9XXXXXXXd6",
              "G-EXXXXXXX3"
          );
        ''');

          if (firstRun) {
            firstRun = false;
            await _controller.executeScript('sign();');
          } else {
            await _controller.executeScript('getResult();');
          }
        }
      });

      _controller.webMessage.listen((event) async {
        if (event['result'] != null) {
          var userData = json.decode(event['result'])['user'];

          debugPrint(userData['uid']);
          debugPrint(userData['email']);
        }
      });

      await _controller
          .loadUrl('http://example.com');

      if (!mounted) return;
      setState(() {});
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Webview(
        _controller,
      ),
    );
  }
}

Aumentando sua instância Ubuntu no Lightsail

Filipe Nanclarez — Tue, 22 Mar 2022 02:06:37 +0000

Hoje precisei fazer um upgrade de um dos sites que tenho hospedado no LightSail. O processo inicial é documentado pela Amazon, mas na prática, a parte que eu mais precisava não estava na documentação. Então depois de pesquisar um pouco, resolvi compartilhar com a comunidade para facilitar.

Segundo a documentação nesse link o que precisamos fazer é criar um snapshot, e depois subir uma outra instância nova a partir desse snapshot.

Então a partir da página inicial do console do LightSail vamos escolher a instância que queremos aumentar e vamos acessar a opção Gerenciar do menu:

Na página da instância, vamos na aba snapshots e vamos usar a opção Criar snapshot. Vamos deixar o nome que ele mesmo sugeriu, e depois cliar em Criar:

Depois que o snapshot for criado, vamos no menu do snapshot e vamos acessar a opção Criar nova instância:

Depois disso vamos apenas dar um nome qualquer e escolher o novo plano que desejamos para essa instância.

Será preciso esperar após a criação. Ela vai aparecer no console como pendente. Após ela constar como em execução, vamos para a parte que não está na documentação.

Redirecionando o ip público

Se seu servidor está sendo usando em produção, então você tem um endereço de ip público associado a essa máquina. Então precisamos apontar esse endereço para a nova instância que criamos.

Para isso, acesse a aba Redes ( na tela inicial do console, não dentro da instâcia ) e no endereço de IP stático em questão, vá na opção Gerenciar do menu:

Escolha a opção Desanexar:

Agora anexe a nova instância a esse endereço estático:

Agora vamos para o próximo ajuste que não está na documentação:

Replicar as regras de firewall para a nova instância

Provavelmente você também tem regras de firewall no seu servidor. Só que quando você cria uma nova instância a partir do snapshot as regras de firewall não são replicadas!

Então acesse a instância antiga, e na aba Redes anote todas as regras que estão listadas para replicar depois. Para facilitar vomos abrir duas abas do navegador e com isso podemos só recriar uma por uma manualmente:

Agora vamos para a última parte

Aumentando o espaço de disco no Ubuntu

Com exceção de sistemas que precisam de ajustes específicos como o PostgreSQL, a memória e o processador já serão utilizados automaticamente pela nova instância. Mas isso não acontece com o espaço em disco. Embora o disco físico seja maior, o sistema operacional não entende que esse espaço está disponível para ser usado.

Então precisamos acessar essa instância e ajustar o tamanho da partição. Para isso vamos usar os utilitários fdisk e o resize2fs:

Primeiro vamos usar o fdisk para apagar a partição atual e criar uma nova com o mesmo setor de inicio.

Então primeiro vamos acessar o fdisk e depois vamos usar o comando p para listar as partições:

sudo fdisk /dev/xvda

Welcome to fdisk (util-linux 2.25.2).                                                                                                                                                           
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/xvda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd7f2e0e8

Device     Boot Start      End  Sectors Size Id Type
/dev/xvda1 *     4096 16773119 16769024   8G 83 Linux

Repare no campo Start que está em 4096. Vamos criar a nova partição iniciando nesse mesmo ponto.

Ainda no modo interativo do fdisk, use a opção d para excluir a partição:

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Agora vamos criar a nova partição usando o comando n. Vamos preencher o primeiro setor com o valor que anotamos:

Command (m for help): n
Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 
First sector (2048-41943039, default 2048): 4096
Last sector, +sectors or +size{K,M,G,T,P} (4096-41943039, default 41943039): 

Created a new partition 1 of type 'Linux' and of size 20 GiB.

Depois disso vamos marcar ela como inicializável com o comando a:

Command (m for help): a
Selected partition 1
The bootable flag on partition 1 is enabled now.

Agora vamos usar o comando p para verificar se está tudo ok:

Command (m for help): p
Disk /dev/xvda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd7f2e0e8

Device     Boot Start      End  Sectors Size Id Type
/dev/xvda1 *     4096 41943039 41938944  20G 83 Linux

Agora que o campo Size já aparece com o tamanho novo, iremos gravar as alterações com o comando w:

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

Opa! Aqui temos um problema. O sistema não vai conseguir fazer a gravação porque essa unidade está montada. O que vamos precisar fazer é dizer para o sistema que queremos que ele aplique essas alterações na próxima vez que o sistema reiniciar. Isso é bem simples, basta criarmos um arquivo com o nome forcefsck na raiz do nosso disco para que o sistema faça exatamente o que precisamos:

sudo touch /forcefsck

Agora vamos reiniciar o servidor e verificar o que aconteceu:

sudo reboot

Ao reiniciar você provavalmente perceberá que o comando df -h continua mostrando o tamanho antigo. Isso acontece porque aumentamos a partição mas não aumentamos o tamanho registrado no sistema de arquivos.

Para corrigirmos isso, vamos utilizar o comando resize2fs que faz exatamente isso:

sudo resize2fs /dev/xvda1
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 3
The filesystem on /dev/xvda1 is now 10485504 (4k) blocks long.

Agora ao executar o comando df-h temos o novo tamanho disponível para uso:

df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            488M     0  488M   0% /dev
tmpfs           100M  3.1M   97M   4% /run
/dev/xvda1       39G   16G   24G  40% /
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
tmpfs           100M     0  100M   0% /run/user/1000

Conclusão.

Como vimos hoje, não basta apenas migrar seu servidor para uma instância maior. É preciso concluir mais algumas etapas para completar essa migração e ter o servidor realmente funcionando em uma instância com mais recursos. Vimos como fazer isso em uma instância com sistema operacional Ubuntu hospedada no serviço LightSail da plataforma AWS da Amazon.

Nos vemos na próxima!

😉

Protegendo a comunicação do Flutter com o Couchbase

Filipe Nanclarez — Sat, 26 Feb 2022 19:12:04 +0000

No primeiro artigo dessa série fizemos uma POC simples mostrando uma alternativa ao Firestore para um aplicativo offline-first construido com flutter.

No segundo artigo instalamos um servidor Couchbase na nuvem usando o serviço Lightsail da Amazon.

Neste artigo iremos configurar o servidor para exigir usuário e senha via TLS (https/wss) e ajustar nosso aplicativo pra funcionar com essa autenticação sem expôr esses em nosso código dart.

Índice

Vamos falar de segurança
Habilitando autenticação no Couchbase Gateway
Configurando TLS (https/wss)
Restringindo os dados
Conclusão

Conforme descrito na documentação há três formas de autenticar o acesso de usuários em nosso Couchbase Gateway.

1 - Autenticação anônima
2 - Autenticação básica
3 - Autenticação usando provedores externos

Desnecessário dizer que se você quer um alto nível de segurança deverá estudar como implantar a terceira opção.

Mas para o nosso projeto vamos usar a segunda opção e aproveitar para abordar um tema bem interessante.

Vamos falar de segurança

Sempre que estudo conteúdo sobre segurança chego no mesmo conceito. Nada é 100% seguro! Geralmente as boas práticas de segurança tem o objetivo de adicionar barreiras para tornar os ataques mais difíceis para um invasor. A quantidade dessas barreiras e o nível de complexidade delas vai depender do seu orçamento. No final das contas é como uma competição de quem tem mais recursos. Você precisa ter mais recursos do que seu inimigo. Ou seja, se seu aplicativo é um aplicativo de banco, com certeza você vai precisar gastar um bom tempo e dinheiro com soluções de segurança de alto nível.

Mas não somos um banco. E há muitos serviços que precisamos acessar que não possuem esse alto nível de segurança em suas estruturas. Muitos serviços de terceiros usam uma autenticação básica em que devemos enviar um token, ou então um usuário e uma senha para validar nosso acesso.

Então vamos fazer a pergunta fatídica: Como usar chaves de API de serviços de terceiros de maneira relativamente segura usando os recursos que temos. Combinamos que não iríamos usar Firebase lembra? Então não iremos usar o Remote Config. Não é que a solução deles seja ruim, mas se você estiver desenvolvendo um aplicativo para Windows terá dificuldade de implementar isso enquanto a INVERTASE não finalizar o desenvolvimento do flutterfire em dart puro.

Então voltando a nossa pergunta, se procurar na internet encontrará vários posts com respostas sobre isso. Mas eu recomendo a leitura desse artigo que aborda o assunto com a devida profundidade. Nele o autor descreve algumas formas de fazer isso e quais são as melhoras.

Segundo a documentação oficial do flutter, podemos usar variáveis de ambiente preenchidas em tempo de compilação para guardar informações sensíveis.

Continuous Integration (CI) systems generally support encrypted environment variables to store private data. You can pass these environment variables using --dart-define MY_VAR=MY_VALUE while building the app.

Isso fará com que esses valores sejam preenchidos apenas no momento que você compila o seu aplicativo.

Então vamos usar essas variáveis para guardar nossa chave, e fazer algumas verificações simples pra confirmar que isso que estamos fazendo traz um nível mínimo de dificuldade para um possível curioso tentando pegar nosso token.

Dentro do código você pode acessar essas variáveis com o seguinte código:

const String apiSecret = String.fromEnvironment('MY_VAR');

Atenção:
Você precisa atribuir o valor a uma variável do tipo const caso contrário o dart não irá atribuir o valor corretamente.

Vamos fazer isso e ver o que acontece. Vou adicionar esse código no inicio do aplicativo que criamos no primeiro artigo. Se eu criar uma variável e nunca usar ela, o processo de compilação remove o código não usado do aplicativo final, então para que nosso teste funcione vou usar um print() logo após receber a variável:

Agora vamos gerar um .apk passando um valor para essa variável no momento da compilação e vamos ver onde e como ela aparecerá para alguém tentando fazer engenharia reversa em nosso aplicativo:

Para gerar o .apk passando as variáveis vamos usar o seguinte comando:

flutter build apk --dart-define MY_VAR=CH@V3S3KR3T@

Vamos usar o jadx para descompilar o apk e ver o código dele. Para detalhes de como fazer isso recomendo esse artigo.

Ao abrir o .apk e procurar nossa chave percebemos que ela não aparece numa busca direta:

Vamos insistir mais um pouco e tentar achar essa chave diretamente em qualquer arquivo inclusive executáveis. Para isso vou descompactar o .apk em uma pasta e usar o Agent Ransack para tentar achar esse valor em qualquer arquivo dentro dessa pasta:

Pronto, achamos ela. Mas como vimos ela não está associada a nenhum nome de variável, e mesmo olhando código puro ela não aparece com facilidade. Se criarmos uma chave complexa com simbolos e de tamanho considerável será mais dificil ainda para um invasor saber o que encontrar. Podemos também codificar ela com algum algoritmo de nossa escolha como o base64, o que faria com o que o invasor tivesse que analisar a lógica do nosso código pra descobrir o que estamos fazendo pra depois tentar achar a chave e decodificar ela de volta e conseguir finalmente acessar nossa API de terceiros. Também podemos usar essa técnica com a url de acesso da api, o que faria com que o atacante perdesse mais tempo ainda identificando o que precisa decodificar e qual valor é usado em qual variável.

Isso já traz dificuldade suficiente para o nosso projeto. Como eu disse acima, há outras soluções mais avançadas que você pode implantar se seu projeto precisa de mais proteção.

Para usar essas variáveis enquanto estiver em modo debug, você precisa adicionar elas na chave toolArgs do seu arquivo launch.json conforme descrito aqui:

Então primeiro vamos configurar o Couchbase Gateway para exigir autenticação com usuário e senha, e depois vamos ajustar nosso aplicativo para usar essas variáveis em tempo de compilação e enviar os dados para o Couchbase Gateway de maneira segura.

Habilitando autenticação no Couchbase Gateway

Lá no começo falamos das três formas de autenticação que o Couchbase Gateway suporta.

A autenticação anônima é a que já está sendo usando na instalação padrão que fizemos. Por isso que conseguimos inserir o documento no banco diretamente pelo powershell sem nenhuma senha.

O que diz para o Couchbase Gateway permitir isso é a seguinte diretiva no arquivo de configurações:

Então o que vamos fazer é desativar o acesso anônimo, e adicionar um usuário com senha nessa lista. Nosso arquivo vai ficar assim:

Reinicie o serviço e verifique se o console está respondendo corretamente, se não estiver revise o arquivo antes de seguir.

Agora se tentarmos fazer a inclusão via powershell, devemos receber o erro de login requerido:

Configurando TLS (https)

Nada do que fizemos faz sentido se a solicitação estiver sendo enviada em texto puro para o servidor. Então o próximo passo é habilitar a comunicação segura entre o nosso aplicativo e o servidor. Para ativar o TLS precisamos de um certificado válido. E para fazer isso direito precisamos de uma autoridade certificadora (CA) do mundo real em vez de usar um certificado auto-assinado. Para isso vamos usar a Let's Encrypt uma CA real que nos permite gerar certificados de forma gratuita.

Para podermos gerar o certificado precisamos de um domínio válido configurado. Se seu projeto for bem pequeno e você não tem um domnínio ainda, a próxima etapa não se aplica a seu caso.

Vou acessar o provedor do meu domínio na parte de DNS e apontar o serviço de DNS para a Amazon.

Depois disso podemos alterar as configurações do DNS diretamente no Lightsail. Acesse o console e na aba Networking, escolha Create DNS zone:

Agora coloque o nome do seu domínio e escolha Create DNS zone:

Depois de criado, vamos na opção adcionar registro:

Preecha conforme imagem abaixo:

Depois disso você deverá ser capaz de acessar as APIs usando o seu dominio em vez de usar o ip:

Se ao tentar acessar seu navegador automaticamente redirecionar para https, você pode desativar isso seguindo esse artigo.

Agora que temos o domínio configurado, vamos gerar o certificado.

Primeiro vamos instalar as dependências:

sudo yum install epel-release -y
sudo yum install snapd -y

Agora vamos ativar o serviço e habilitar o suporte clássico conforme descrito aqui:

sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

Agora vamos instalar o certbot:

sudo snap install --classic certbot

Agora vamos criar os certificados:

sudo certbot certonly --standalone -d example.com

Ao fazer isso serão criados os seguintes arquivos:

/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/privkey.pem

Vamos dar permissão de leitura para esses arquivos:

sudo chmod -R 755 /etc/letsencrypt

Agora vamos configurar o Couchbase Gateway para usar esse certificado. Ao fazer isso ele automaticamente passa a usar TLS na comunicação da API. Conforme descrito nessa parte da documentação, devemos adicionar o caminho dos arquivos do certificado e da chave no nosso arquivo de configuração do Couchbase Gateway.

Reinicie o serviço e teremos a API respondendo via HTTPS.

Com isso temos o servidor devidamente configurado para ser acessado através via TLS e exigindo usuário e senha.

Agora vamos voltar para o flutter e ajustar nosso app para utilizar o usuário e senha que criamos e sincronizar usando TLS.

O que vamos fazer é o seguinte. Vamos adicionar o parametro authenticator nas configurações do replicador. Nele vamos passar o usuário e a senha que configuramos no Couchbase Gateway.

Mas como falamos no começo do artigo, esses valores não iremos digitar direto no código. Vamos trazer eles através das variáveis preenchidas em tempo de execução. Vamos aproveitar e fazer isso também para a url da API do Couachbase Gateway. Também vamos usar base64 para ofuscar elas.

Então vamos começar declarando e populando as variáveis.

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;
  Database? database;
  var replicator;

  // Aqui recebemos as variáveis que virão do ambiente via dart-define
  static const String constCouchGwUser = String.fromEnvironment('couchGwUser');
  static const String constCouchGwPass = String.fromEnvironment('couchGwPwd');
  static const String constEndPointUrl = String.fromEnvironment('endPointUrl');

  // Aqui decodificamos de base64 para o valor original
  String couchGwUser = Utf8Codec().decode(base64Decode(constCouchGwUser));
  String couchGwPwd = Utf8Codec().decode(base64Decode(constCouchGwPwd));
  String endPointUrl = Utf8Codec().decode(base64Decode(constEndPointUrl));

  Future<void> _incrementCounter() async {

Agora vamos alterar as configurações do replicador. Vamos usar a variável da url do endpint que criamos, e vamos incluir o parâmetro authenticator passando um objeto do tipo BasicAuthenticator com o nome de usuário e a senha:

// replicador
replicator = await Replicator.create(
  ReplicatorConfiguration(
    database: database!,
    target: UrlEndpoint(Uri.parse(endPointUrl)),
    // authenticador
    authenticator: BasicAuthenticator(username: couchGwUser, couchGwPwd: key),
  ),
);

O valor das variáveis nós iremos enviar em base64, então vamos codificar esses valores usando o site base64encode.org:

O usuário:

A senha:

E agora a url do endpoint:

Importante!
Nós precisamos mudar a url porque agora a comunicação será via TSL então em vez de usar o prefixo ws:// vamos usar wss://:

Para podermos usar essas variáveis em modo debug vamos alterar o lauch.json da seguinte forma:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "poc_flutter_couchbase",
            "request": "launch",
            "type": "dart",
            // Variaveis que serão passadas em tempo de compilação
            "toolArgs": [
                "--dart-define",
                "couchGwUser=c3luY19jbGllbnQ=",
                "--dart-define",
                "couchGwPwd=Q0hAVjNTM0tSM1RA",
                "--dart-define",
                "endPointUrl=d3NzOi8vZXhhbXBsZS5jb206NDk4NC9teS1kYXRhYmFzZQ==",
            ]
        },
        {
            "name": "poc_flutter_couchbase (profile mode)",
            "request": "launch",
            "type": "dart",
            "flutterMode": "profile"
        }
    ]
}

Rode o programa e faça o teste, se tudo estiver certo você verá no log que o documento foi incluido e verá no servidor que o documento foi criado com sucesso.

Restringindo os dados

Por último vamos falar de um problema que precisamos eliminar se quisermos usar isso tudo em um aplicativo real.

Imagine que fizemos tudo isso, e agora desenvolvemos um aplicativo para que os usuários guardem suas anotações pessoais.

Da forma como o código está, se 10 usuários estiverem usando o aplicativo e incluirem 10 notas, todos os 10 usuários receberão 100 notas durante a sincronização. Ou seja, não há nenhum filtro. Você pode pensar em fazer um filtro no seu código, mas isso não impediriam que os dados fossem enviados para o seu aplicativo, o que sobrecarregaria a conexão do usuário, sem falar na franquia. Só quando todos os dados de todos os usuários chegassem no seu aplicativo é que você descartaria os registros. Imagina isso em escala, para mil usuários, um milhão. Acho que já deu pra entender o problema.

A solução seria de alguma forma informar ao servidor que durante a sincronização ele só deve nos enviar dados do usuário atual, não de todos os documentos.

Para isso existe o recurso de 'canais' no couchbase. Quando criamos o replicador podemos dizer quais 'canais' queremos escutar. Com isso o replicador só irá receber documentos desses 'canais' que definirmos.

No nosso exemplo, podemos criar um canal específico para o usuário, e configurar o replicador para receber somente documentos desse usuário.

Para isso vamos alterar novamente o código da seguinte forma:

// replicador
replicator = await Replicator.create(
  ReplicatorConfiguration(
    database: database!,
    target: UrlEndpoint(Uri.parse(endPointUrl)),
    channels: ['userA'],
    // authenticador
    authenticator: BasicAuthenticator(username: couchGwUser, couchGwPwd: key),
  ),
);

Com isso estamos dizendo que desejamos receber dados apenas do userA. É claro que você deve usar uma váriavel aqui que tenha o identificador do seu usuário.

Depois de fazer isso no replicador precisamos fazer mais uma coisa. Toda vez que enviarmos um documento para o servidor, precisamos registrar no documento a qual canal aquele documento pertence. A configuração de canais é bem flexível, podemos alterar o script do gateway para buscar isso de um campo específico ou usar qualquer lógica que atenda nossa necessidade. Mas por padrão o gateway irá definir o canal do documento usando o campo channels que aceita uma lista de valores. Então na criação do documento iremos alterar o código da seguinte forma:

    final doc = MutableDocument({
      'type': 'logMessage',
      'createdAt': DateTime.now(),
      'message': 'teste',
      'channels': ['userA'] // canal que esse documento será atribuido
    });

Com isso nosso aplicativo só irá sincronizar dados referente ao usuário userA.

Conclusão

Nessa série de artigos implementamos uma solução offline-first em Flutter sem usar os serviços do Google Firebase.

Criamos um VPS (Servidor Virtual Privado) na Amazon usando o Lightsail.
Instalamos o Couchbase Server e o Couchbase Gateway no Centos7.
Criamos os certificados usando a Let’s Encrypt como CA (Autoridade Certificadora) e ativamos o TLS (Transport Layer Security) para que a comunicação seja feita via https/wss.
Configuramos a API do Couchbase Gateway para exigir autenticação básica (usuário e senha).
Usamos o aplicativo de demonstração do Flutter para gravar os dados de modo offline e depois sincronizar esses dados com o Couchbase Gateway.
Usamos dart-define para não expor a senha em nosso código.
Configuramos um canal para filtrar o envio e recebimento dos documentos do nosso usuário.

Não achei muito material abordando esse tema, especialmente em português então espero que esses artigos sejam úteis para quem precisar.

😉

Couchbase Server e Gateway no AWS Lightsail

Filipe Nanclarez — Sat, 26 Feb 2022 19:11:29 +0000

No primeiro artigo dessa série, fizemos uma POC simples gravando dados em uma instância do Couchbase embutida no aplicativo de exemplo padrão do flutter. Além disso instalamos em nosso ambiente local uma versão de servidor do Couchbase e configuramos um gateway para que nosso aplicativo se comunicasse com o servidor. E por fim finalizamos fazendo uma sincronização dos dados do nosso aplicativo para o servidor.

Nesse artigo vamos fazer a instalação do servidor em um servidor virtual hospedado na Amazon.

Índice

Criando o servidor
Instalando o Couchbase Server
Instalando o Couchbase Gateway

Criando o servidor

No artigo passado citamos dois tipos de serviço na nuvem. O Lightsail e o EC2. De forma resumida, a diferença entre eles é que o Lightsail simplifica as coisas para quem está começando. Se você decidir usar o EC2 você tem o benefício de poder usar gratuidamente por um ano. Em contrapartida terá que se preocupar com as redes VPS, com o funcionamento do LoadBalancer etc. Usando Lightsail você terá apenas três meses gratuitos, mas terá menos coisas para configurar. Mantendo o conceito do artigo anterior, vamos criar o servidor usando o serviço Lightsail e futuramente se você quiser migrar para o EC2 poderá fazer isso sem maiores problemas.

Vamos acessar o site oficial e usar o grande botão laranja bem no meio da tela:

Na tela de autenticação ele irá nos perguntar se queremos logar ou queremos criar uma nova conta. Vamos criar uma nova conta:

Prencha com seu e-mail e um nome de usuário e prossiga:

Depois das verificações de e-mail e segurança será preciso escolher uma senha.

Em seguida ele pedirá informações de contato. Não coloque acentos no nome da cidade e do estado. Depois siga para informações de faturamento, e por ultimo confirmação de contato por sms ou ligação de voz.

Depois disso você poderá escolher o nível de suporte. Vou seguir com o suporte gratuito.

Por fim, veremos a tela de conclusão do cadastro. Vamos usar o botão laranja novamente para acessar o Console de Gerenciamento da AWS.

Depois de fazer login denovo, caimos na tela principal do console. Mas não vamos usar esse console. Vamos usar o console do Lightsail, então use esse endereço: https://lightsail.aws.amazon.com/

Aqui poderemos escolher a opções para criação da nossa instância. Não irei mudar a região da instancia. Em seguida vamos escolher a plataforma Linux/Unix e o blueprint vamos escolher Os Only e escolher CentOS 7 (o CentOS 8 já perdeu o suporte, enquanto o 7 vai até 2024).

Mais abaixo na página, vamos escolher a opção com 2gb de memória RAM de acordo com os requisitos mínimos do Couchbase Server. Em seguida vamos escolher um nome para a instância.

Depois disso basta clicar no botão Create instance

O console irá mostrar a instância como pendente por um tempo, basta aguardar:

Depois que ela estiver rodando, precisamos acessar ela via ssh. Para isso acesse o menu Account no canto superior direito. Na tela seguinte acesse a aba SSH Keys. Faça o download da chave pelo link conforme imagem a seguir:

Antes de podermos usar essa chave, vamos precisar converter ela para o formato suportado pelo putty. Abra o puttygen e escolha o botão Load e escolha o arquivo .PEM que baixamos:

Agora clique em Save private key. Ele vai perguntar se deseja salvar sem definir uma senha. Eu decidi seguir sem senha e depois escohi um lugar para o arquivo.

Agora podemos usar essa chave para acessar o servidor via putty. Insira o arquivo na seguinte configuração:

Depois disso vamos voltar na primeira sessão e preencher o IP do servidor para podermos fazer o acesso:

Ao fazer o acesso será solicitado o usuário, que no padrão para essa imagem de sistema que escolher é centos. E pronto, temos acesso ao shell do nosso servidor:

Antes de seguirmos, vamos criar um endereço de IP fixo para essa instância, senão toda vez que reiniciarmos o servidor ele vai iniciar com um IP diferente.

Acesse a aba Networking e escolha a opção Create static IP.

Escolha a instancia que criamos, defina o um nome para o IP stático e clique em Create.

Depois da criação será exibido o novo IP estático que iremos usar agora no nosso putty de forma permanente.

Agora que já estamos com nossa instância no ar, vamos partir para a instalação e configuração do servidor Couchbase e do Gateway.

Instalando o Couchbase Server

Vamos começar atualizando os pacotes:

sudo yum update -y

Seguindo as instruções da documentação vamos digitar os comandos abaixo:

curl -O https://packages.couchbase.com/releases/couchbase-release/couchbase-release-1.0-x86_64.rpm

sudo rpm -i ./couchbase-release-1.0-x86_64.rpm

sudo yum install couchbase-server-community -y

Agora vamos abrir as portas necessárias no firewall da AWS:

Use a opção Manage no console para acessar as configurações da instância:

Agora na abra Networking e use o botão Add rule para incluir as portas conforme imagem abaixo:

Com isso será possível acessar o console do Couchbase Server:

A partir daqui o passo a passo já foi abordado no artigo anterior dessa série, então vou passar agora para a instalação do Couchbase Gateway.

Instalando o Couchbase Gateway

Vamos precisar baixar um pacote, então vamos instalar o wget primeiro:

sudo yum install wget -y

Agora seguindo o passo-a-passo da documentação vamos baixar o pacote com o comando abaixo:

wget http://packages.couchbase.com/releases/couchbase-sync-gateway/3.0.0-beta02/couchbase-sync-gateway-community_3.0.0-beta02_x86_64.rpm

E agora a instalação:

sudo rpm -i couchbase-sync-gateway-community_3.0.0-beta02_x86_64.rpm

O resultado é o gateway já rodando na porta 4984.

Vamos adicionar essas portas também ao firewall:

Assim como no artigo anterior, nesse ponto você precisa conseguir acessar o gateway e obter o retorno da API. Se não conseguir obter esse retorno, pare e revise os passos anteriores:

Agora vamos acessar as configurações do gateway e apontar ele para nosso servidor couchbase:

sudo nano /home/sync_gateway/sync_gateway.json

Vamos alterar da mesma forma que fizemos no artigo anterior:

{
  "adminInterface": "127.0.0.1:4985",
  "interface": "0.0.0.0:4984",
  "databases": {
    "my-database": {
      "server": "http://127.0.0.1:8091",
      "bucket": "my-database",
      "username": "sync_gateway",
      "password": "******",
      "enable_shared_bucket_access": true,
      "import_docs": true,
      "num_index_replicas": 0,
      "users": {
        "GUEST": { "disabled": false, "admin_channels": ["*"] }
      }
    }
  },
  "logging": {
    "console": {
      "log_level": "debug",
      "log_keys": ["*"]
    }
  }
}

Denovo... você precisa conseguir acessar a API após essa alteração antes de continuar.

Agora vamos executar o mesmo teste que fizemos no artigo anterior via poweshell para confirmar que tudo está funcionando corretamente:

E acessando o Couchbase Server devemos ver o registro que acabamos de inserir:

É isso aí! Temos um servidor na nuvem pronto para receber as requisições do nosso aplicativo.

No próximo artigo dessa série, vamos falar um pouco sobre segurança.

Nos vemos lá.

Eu tenho um sonho ... offline-first em Flutter

Filipe Nanclarez — Sat, 26 Feb 2022 19:10:19 +0000

Quando pensamos em desenvolvimento de aplicativos, logo nos lembramos dos problemas de conexão que todos os usuários enfrentam. E como desenvolvedor com certeza você já deve ter ouvido a pergunta de um milhão: "como fazer offline-first?". Sempre que fiz essa pergunta a resposta foi "isso é complicado". Ao mesmo tempo sempre ouço "tem o firebase, mas ...".

De fato a solução da Google é muito atraente. Principalmente para quem está começando e não quer gastar muita energia com a parte de backend, servidores, configuração de clusters, etc.

Mas ele tem suas limitações, e essas limitações acabam levando os desenvolvedores a buscar outras soluções cedo ou tarde, principalmente quando esbarram em algum problema que ele não pode resolver.

No meu caso, eu até poderia aceitar a ideia de pagar um pouco mais pelo serviço, afinal era só uma questão matemática, o quanto eu iria cobrar dos meus usuários seria equivalente ao uso. Quanto mais usuários, mais receita e o custo ia crescer de acordo. Mas o que me fez ir atrás de outra solução foi uma limitação técnica. O limite do tamanho do registro do Firestore. Conforme a documentação um documento não pode ter mais de 1 MiB. Meu aplicativo precisa de mais que isso. Tentei quebrar o conteúdo, mas isso me trouxe mais problemas do que soluções.

Acabei focando em outras partes do aplicativo que precisavam ficar prontas, e deixei esse assunto na gaveta. Até que um dia me deparei com o artigo How to make your Flutter app offline-first with Couchbase Lite. Isso me chamou bastante atenção e após ler ele superficialmente deixei ele guardado na gaveta.

Algum tempo depois meu aplicativo já estava publicado, os usuários estavam contentes, e o problema que eu havia conscientemente jogado para o canto da mesa, agora precisava ser resolvido.

Então arregacei as mangas e comecei a trilhar esse caminho.

O que vem a seguir é baseado nesse artigo do Gabriel Terwesten e na documentação do próprio site da Couchbase. Algumas imagens foram tiradas dessas fontes.

Os pacotes usados nesse artigo até o momento não dão suporte para web, então se você tem projetos web não vai conseguir, por enquanto, usar essa solução. 😉

Índice

O aplicativo
O servidor
O gateway
Conferindo a comunicação
O replicador
Conclusão

Mas o que é essa tal de Couchbase?

A Couchbase fornece uma solução de banco de dados bem robusta e com características interessantes. A solução é de código aberto, e possui uma versão gratuita mantida pela comunidade.

No caso do flutter, o autor do artigo mencionado acima explica porque ele criou os packages que vamos usar abaixo.

Ao procurar esses packages no pub.dev você talvez fique confuso porque são vários packages separados. Segundo o artigo, basicamente o pacote com que nós iremos interagir é o cbl_flutter ou o cbl_dart. Se você como eu está se perguntado se deve usar o cbl_dart porque seu aplicativo precisa rodar em qualquer plataforma, fique tranquilo, o cbl_flutter também roda.

Esse pacote depende do clb, que depende do cbl_ffi que depende de outros e assim por diante. Para facilitar vamos nos concentrar apenas nas dependências necessárias e fazer uma POC simples pra ver o negócio funcionando.

O aplicativo...

Nosso foco é o couchlite, então não vamos perder tempo com layout nem perfumaria. Vamos fazer o seguinte, vamos pegar o projeto padrão do flutter, e na rotina que incrementa o contador, vamos fazer o aplicativo gravar uma informação no banco. Simples assim! Com isso vamos entender o funcionamento e arquitetura da solução da Couchbase sem gastar energia com detalhes que apenas ofuscariam nossa visão do conceito principal.

Então vamos lá.

Crie uma pasta com o nome que quiser, e estando dentro dela abra seu prompt e inicie o projeto padrão do flutter.

flutter create .

Isso vai criar aquele projeto que todos nós conhecemos do contador:

Agora vamos adicionar as dependências no pubspec.yaml. Se você for no pub.dev procurar o package cbl, e for ler o readme, vai ficar surpreso com a parte da instalação:

Legal, eles não colocaram as versões. Mas isso nunca foi um problema certo, basta eu usar o método flutter pub add.

Então vamos fazer isso para todos os pacotes que precisamos. Você já vai entender porque estou detalhando um passo tão óbvio.

De cima pra baixo, vamos instalar:

O pacote principal da biblioteca:
flutter pub add cbl

Depois o pacote do clb_flutter
flutter pub add cbl_flutter

E por último o pacote especifico do flutter, na versão comunity do couchlite:
flutter pub add cbl_flutter_ce

E aí somos surpreendidos com esse erro curioso:

Because cbl_flutter_platform_interface >=1.0.0-beta.1 <1.0.0-beta.2 depends on cbl ^1.0.0-beta.7 and cbl_flutter_platform_interface <1.0.0-beta.1 depends on cbl ^1.0.0-beta.6, cbl_flutter_platform_interface <1.0.0-beta.2 requires cbl ^1.0.0-beta.6.
And because cbl_flutter_ce <1.0.0-beta.2 depends on cbl_flutter_platform_interface ^1.0.0-beta.0 and cbl_flutter_ce >=1.0.0-beta.2 <1.0.0-beta.3 depends on cbl_flutter_platform_interface ^1.0.0-beta.2, cbl_flutter_ce <1.0.0-beta.3 requires cbl ^1.0.0-beta.6 or cbl_flutter_platform_interface ^1.0.0-beta.2.
And because cbl_flutter_platform_interface >=1.0.0-beta.2 <1.0.0-beta.3 depends on cbl ^1.0.0-beta.8 and cbl_flutter_ce >=1.0.0-beta.3 <1.0.0-beta.4 depends on cbl_flutter_platform_interface ^1.0.0-beta.3, cbl_flutter_ce <1.0.0-beta.4 requires cbl ^1.0.0-beta.6 or cbl_flutter_platform_interface ^1.0.0-beta.3.
And because cbl_flutter_platform_interface >=1.0.0-beta.3 <1.0.0-beta.4 depends on cbl ^1.0.0-beta.10 and cbl_flutter_ce >=1.0.0-beta.4 <1.0.0-beta.6 depends on cbl_flutter_platform_interface ^1.0.0-beta.4, cbl_flutter_ce <1.0.0-beta.6 requires cbl ^1.0.0-beta.6 or cbl_flutter_platform_interface ^1.0.0-beta.4.
Because cbl_flutter_platform_interface >=1.0.0-beta.5 <1.0.0-beta.6 depends on cbl ^1.0.0-beta.13 and cbl_flutter_platform_interface >=1.0.0-beta.4 <1.0.0-beta.5 depends on cbl ^1.0.0-beta.11, cbl_flutter_platform_interface >=1.0.0-beta.4 <1.0.0-beta.6 requires cbl ^1.0.0-beta.11.
Thus, cbl_flutter_ce <1.0.0-beta.6 requires cbl ^1.0.0-beta.6 or cbl_flutter_platform_interface ^1.0.0-beta.6.
And because cbl_flutter_ce >=1.0.0-beta.6 depends on cbl_flutter_platform_interface ^1.0.0-beta.6 which depends on cbl ^1.0.0-beta.15, every version of cbl_flutter_ce requires cbl ^1.0.0-beta.6.
So, because poc_flutter_couchbase depends on both cbl ^0.6.0+1 and cbl_flutter_ce any, version solving failed.

O erro já explica o que está acontecendo. As versões do pub.dev não estão sincronizadas corretamente.

Pra conseguir pegar a versão correta, basta clicar na versão 'Prerelease' lá no pub.dev. Com isso será possível ver as versões que ainda estão em desenvolvimento

Se você não quer perder tempo com isso, basta colocar as seguintes versões no seu pubspec.yaml:

  cbl: ^1.0.0-beta.15
  cbl_flutter: ^1.0.0-beta.13
  cbl_flutter_ce: ^1.0.0-beta.6

Agora vamos ao código. Você pode vasculhar a documentação no site da Couchbase e também dos pacotes para ver exemplos de como fazer um CRUD simples.

No nosso caso, vamos manter o foco em inserir alguma coisa no banco. Então primeiro precisamos iniciar o banco. Para isso vamos adicionar no método iniState um 'PostFrameCallback' com a chamada para iniciar e abrir o banco. Se você é novo em flutter, estamos colocando aqui, para que essa inicialização aconteça apenas uma vez.

  @override
  void initState() {
    // TODO: implement initState
    super.initState();
    WidgetsBinding.instance?.addPostFrameCallback((timeStamp) async {
      await CouchbaseLiteFlutter.init();
      database = await Database.openAsync('database-example');

    });
  }

Depois de iniciar o banco, agora podemos usar ele em nossa aplicação.

Na função _incrementCounter() vamos inserir os comandos para inclusão de um registro no banco. Basicamente criamos um documento e depois usamos o método saveDocument() pra salvar ele no banco:

  Future<void> _incrementCounter() async {
    final doc = MutableDocument({
      'type': 'logMessage',
      'createdAt': DateTime.now(),
      'message': 'teste',
    });

    await database?.saveDocument(doc);

    setState(() {
      _counter++;
    });
  }

Agora para podermos ver o registro que foi inserido, vamos precisar consultar o banco e trazer os resultados.

Então vamos fazer um select simples, e imprimir isso no log. Mude novamente a função para isso:

    Future<void> _incrementCounter() async {
    final doc = MutableDocument({
      'type': 'logMessage',
      'createdAt': DateTime.now(),
      'message': 'teste',
    });

    await database?.saveDocument(doc);

    // consultando dados no banco
    final query = const QueryBuilder()
        .select(
          SelectResult.expression(Meta.id),
          SelectResult.property('createdAt'),
          SelectResult.property('message'),
        )
        .from(DataSource.database(database!))
        .where(
          Expression.property('type').equalTo(Expression.value('logMessage')),
        )
        .orderBy(Ordering.property('createdAt'));

    ResultSet resultSet = await query.execute();
    var results = await resultSet.asStream().map((result) => result.toPlainMap()).toList();

    print(results[0]['id']);
    print(results[0]['createdAt']);
    print(results[0]['message']);

    await replicator.start();

    setState(() {
      _counter++;
    });
  }

Execute o aplicativo, aperte o botão de incrementar e se tudo der certo você verá os dados que acabou de inserir no console assim:

Com isso já temos um aplicativo gravando dados e exibindo esses dados. Uma POC bem simples, pra mostrar como funciona a parte 'lite' do Couchbase.

Vamos agora dar um passo a mais.

O servidor...

Nós começamos esse artigo falando sobre a necessidade do offline-first e do Firestore. Agora nós criamos uma POC gravando dados num app. Mas isso está mais parecido com Sqlite do que com Firestore certo? Certo!

Para que tudo isso fique mais parecido com o Firestore, precisamos de um servidor, e precisamos que o aplicativo e o servidor sincronizem os dados de forma transparente para o usuário ( se também for transparente para os desenvolvedores... melhor ainda ).

Então vamos lá, vamos instalar um servidor de banco de dados. Vamos continuar mantendo as coisas simples e diretas, mas para que você entenda a proposta da solução, a ideia é que no final você possa contratar uma VM na nuvem, e você tenha seu próprio servidor. Por exemplo você poder usar o serviço Lightsail da AWS ou ainda usar o EC2 e ter um servidor gratuito por um ano. Ou usar outros provedores para ter seu próprio servidor na nuvem. Depois você instala o Couchserver nesse servidor, e com isso você terá uma solução para usar no lugar do Firestore, com a vantagem de não ter as limitações que já mencionamos.

Então vamos lá. Vamos instalar o servidor no nosso computador local mesmo, e fazer isso tudo funcionar. Depois pensamos em como colocar isso em um servidor na nuvem.

Para baixar o Couchbase server acesse a página oficial nesse link

Em Couchbase Server escolha a versão community, no meu caso estou usando essa aqui:

Depois da instalação, seguindo a documentação em Create a Cluster devemos acessar o console do Couchbase Server pelo navegador na porta padrão 8091. Vamos cair nessa página:

Vamos escolher a opção "Setup New Cluster"

O nome do cluster fica a seu critério. Deixei o meu setup da seguinte forma:

Após isso verá a tela dos termos. Após as opções de aceitar os termos, há duas opções; terminar com os padrões ou configurar disco memória e serviços.

Para fins didáticos, vamos escolher a opção 'Configure Disk, Memory, Services'.

Nessa tela, podemos ver as opções disponíveis. Eu não vou mudar nada no meu setup, mas achei bom trazer vocês até aqui para vocês conhecerem as opções disponíveis.

Após clicar em finalizar, seremos redirecionados para o Dashboard principal desse nó, conforme imagem abaixo:

Agora vamos precisar criar nosso bucket, para armazenar nossos dados. Clique em bucket no menu de opções:

Depois clique em 'ADD BUCKET'

Aqui vou apenas escolher o nome. No print abaixo, deixei aberta as opções avançadas apenas para fins didáticos:

O gateway...

A comunicação com o servidor não é direta. É necessário um intermediário entre uma instancia local do CouchLite (seu aplicativo) e o Servidor Couchbase.

Para entender melhor o fluxo, veja essa imagem tirada do site da couchbase:

Ou seja, nosso aplicativo fala como gateway, e o gateway fala com o servidor. Então bora instalar esse cara!

A instalação segue o padrão NNF (Next, Next, Finish).

Após finalizar, vamos ter as informações sobre a porta em que o gateway estará rodando. Anote isso!

Agora vamos acessar esse endereço que anotamos.

Deve aparecer isso na tela:

Isso significa que deu certo a instalação. Caso não tenha aparecido esse retorno da API pare aqui e repasse a instalação antes de seguir.

Agora precisamos configurar o Gateway para acessar o servidor do CouchBase. Primeiro vamos criar um usuário para que o gateway possa acessar o servidor.

Acesse Security e depois o botão 'ADD USER' conforme imagem abaixo:

Preencha o nome, e a senha, e nas permissões deixe da seguinte forma:

Agora vamos parar serviço do gateway lá em services.msc (no windows). Depois que o serviço estiver parado vamos editar o arquivo de configurações do gateway. Na minha instalação está em c:\Program Files\Couchbase\Sync Gateway\serviceconfig.json. Após achar o arquivo edite ele e altere o json pra ficar parecido com isso (preencha com as suas informações é claro, principalmente a senha):

{
  "adminInterface": "127.0.0.1:4985",
  "interface": "0.0.0.0:4984",
  "databases": {
    "my-database": {
      "server": "http://127.0.0.1:8091",
      "bucket": "my-database", 
      "username": "sync_gateway", 
      "password": "******",
      "enable_shared_bucket_access": true, 
      "import_docs": true, 
      "num_index_replicas": 0, 
      "users": {
        "GUEST": { "disabled": false, "admin_channels": ["*"] } 
      }
    }
  },
  "logging": { 
    "console": {
      "log_level": "debug",
      "log_keys": ["*"]
    }
  }
}

Depois disso, inicie novamente o serviço. Você deve conseguir ver o retorno da API novamente ao tentar acessar o gateway pelo navegador em localhost/4985. Se não conseguir, pare e reveja passo a passo. Uma dica importante. Eu perdi um tempo considerável aqui, por conta de porta travada no computador. Se você reviu o passo a passo, e ainda não consegue acessar, sugiro que reinicie o computador. No meu caso foi o suficiente para o gateway responder corretamente após os ajustes.

Conferindo a comunicação

Para termos certeza de que tudo está ok, vamos inserir dados no servidor via API do gateway. Poderíamos fazer essa requisição de várias formas, usando postman por exemplo. Mas para facilitar vou usar a requisição com o curl, via powershell com o cmdlet Invoke-WebRequest. Abra uma janela do powershell e cole o comando abaixo (lembre de trocar o nome do bucket na url):

iwr http://localhost:4984/my-database/ `
-Method 'POST' `
-ContentType 'application/json; charset=utf-8' `
-Body '{ 
  "_id": "first-doc", 
  "name": "Hello Word Couchbase", 
  "type": "teste-doc", 
  "data": "Hello Word" 
}'

Devemos obter esse retorno:

Agora vamos no couchserver, verificar o documento criado:

Olha ele aí:

Com isso sabemos que o gateway está ok. Agora vamos voltar ao flutter.

O replicador...

Vamos adicionar no PostFrameCallback um replicador. Esse cara será chamado toda vez que quisermos sincronizar alguma coisa com o servidor. Pode ser após inserir uma informação, ou quando o aplicativo iniciar, ou quando ele voltar a ter conexão com a internet, enfim, você que escolhe em que momento ele deverá fazer isso. No momento da sincronização ele envia e recebe os dados do servidor (via gateway) e em caso de conflito (se o registro foi editado tanto no servidor quanto na aplicação antes da sincronização) a resolução de conflitos padrão escolhe como vencedor o último registro que foi gravado.

Abaixo o código modificado do método iniState(). Repare que também adicionamos um listener para printar o status do replicador. Você pode por exemplo usar isso para exibir algum loader no aplicativo. Aqui estamos apenas imprimindo no console as mudanças de estado:

  @override
  void initState() {
    // TODO: implement initState
    super.initState();
    WidgetsBinding.instance?.addPostFrameCallback((timeStamp) async {
      await CouchbaseLiteFlutter.init();
      database = await Database.openAsync('example.couchbase');

      // replicador
      replicator = await Replicator.create(
        ReplicatorConfiguration(
          database: database!,
          target: UrlEndpoint(Uri.parse('ws://localhost:4984/my-database')),
        ),
      );

      await replicator.addChangeListener((change) {
        debugPrint('Replicator activity: ${change.status.activity}');
      });
    });
  }

esse código só cria o 'replicator' mas não dispara uma sincronização. Então vamos adicionar uma sincronização logo após o usuário apertar o botão para incrementar o contador. Assim o sistema irá adicionar um registro e logo em seguida irá disparar uma sincronização:

  Future<void> _incrementCounter() async {
    final doc = MutableDocument({
      'type': 'logMessage',
      'createdAt': DateTime.now(),
      'message': 'teste',
    });

    await database?.saveDocument(doc);

    await replicator.start();

    setState(() {
      _counter++;
    });
  }

Faça o teste, e se tudo der certo, você verá no console do couchserver os documentos. Se você for como eu, talvez dê alguns pulos de alegria também.

Você pode fazer alguns testes parando o serviço do Couchbase Server, gravando dados no aplicativo, depois iniciando o serviço denovo e incluindo mais dados e depois verificando se tanto os dados gerados enquanto você estava com o servidor parado quanto os dados gerados após o servidor estar novamente em execução foram gravados corretamente.

Conclusão

O que fizemos até aqui já deve ter dado uma bela clareada na sua mente sobre como isso tudo funciona. Mas é claro que isso é uma POC bem simples, e com certeza precisamos fazer mais coisas, como exibir os dados de maneira mais elegante, filtrar os dados a serem sincronizados (afinal não queremos dados de todos os outros usuários que usam o aplicativo sobrecarregando nosso celular), criar alguma forma de autenticar em nosso gateway para evitar que qualquer um possa inserir dados via powershell como fizemos, sem falar na parte de configurar um servidor na nuvem para que a coisa fique mais parecida com a realidade.

Ainda temos um bom caminho pela frente.

No próximo artigo vamos dar uma olhada em tudo isso.