DEV Community: Iaan Mesquita

Observer Pattern: Keeping Components in Sync

Iaan Mesquita — Sun, 27 Aug 2023 16:32:05 +0000

Hi again,

If you don't know me, my name is Iaan Mesquita.

Today, we'll discuss about Observer Pattern - Behavioral Pattern.

Also known as: Event-Subscriber and Listener

I recommend you start from my last article (Factory Method: Simplifying Object Instantiation) because there are some concepts that are good to know before starting this.

Note: Like I said in the previous article, not always I'll use the best approaches to explain the pattern because I want to make the article simpler for those who don't know about this pattern

And also, it's good to have an understanding of Object-Oriented Programming (OOP) and SOLID principles.

Summary

Concepts
Problem
Resolving problem without Observer pattern
Observer Pattern
Conclusion
References

As you know, before we start, let's take a look at a concept.

Concepts

Don't Repeat Yourself (DRY)

Don't Repeat Yourself (DRY) is a software development principle aimed at reducing the repetition of code patterns. The main idea behind DRY is to eliminate redundant code: if you have two or more identical code blocks in different parts of your software, you might be doing something wrong.

The main advantage of this principle is that it has better maintainability in the entire lifetime of your software. Imagine you have a lot of places inside your code that are the same, if you change the behavior of it you need to change it in a lot of places.

But, don't take this principle strictly true, you need to understand WHEN and HOW to apply it to work well. DRY shouldn't be a problem or concern for you.

We can discuss in the future a good example of "DRY(ing) in a bad way"

Problem

Taylor Alexis is a smart person, currently, she works in a big company that sells a lot of video games, but there are two that are the most sold and are very disputated: Playstation and Xbox.

And she knows these two brands have a lot of fanboys that can not hear the other brand's name because they get very mad.

But the business doesn't care and just wants to sell a lot of video games, whatever fanboys they are. These video games sell so fast but there is a waitlist that they subscribe to and get emailed when the video game has come into the store.

Despite the business needs to sell a lot, whatever kind of fanboys they were, it's not a good idea to send an email that they don't want to. Like: "THE BEST CONSOLE EVER HAS COME TO OUR STORE: PLAYSTATION / XBOX".

Resolving problem without Observer pattern

Taylor had been on vacation when everything happened, and the team decided to implement one solution for this:

import { Email, Whatsapp, SMS } from '../services'

class SendMessageToWaitlisteners {
    constructor(
            private readonly serviceName: string,
            private readonly xboxSubscribersList,
            private readonly playstationList
        ) {
        if (serviceName == 'email') {
            for (const contactInfo of xboxSubscribersList)
                new Email(contactInfo.email).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: XBOX')
            for (const contactInfo of playstationList)
                new Email(contactInfo.email).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: PLAYSTATION')
        }
    }
}

But the customers started to complain because they don't use Email, they use WhatsApp and SMS and they wanted receive the message through these platforms. So the team implemented the other behaviors:

import { Email, Whatsapp, SMS } from '../services'

class SendMessageToWaitlisteners {
    constructor(
        private readonly serviceName: string,
        private readonly xboxSubscribersList,
        private readonly playstationList
    ) {
        if (serviceName == 'email') {
            for (const contactInfo of xboxSubscribersList)
                new Email(contactInfo.email).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: XBOX')
            for (const contactInfo of playstationList)
                new Email(contactInfo.email).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: PLAYSTATION')
        } else if (serviceName === 'whatsapp') {
            for (const contactInfo of xboxSubscribersList)
                new Whatsapp(contactInfo.numberPhone).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: XBOX')
            for (const contactInfo of playstationList)
                new Whatsapp(contactInfo.numberPhone).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: PLAYSTATION')
        }
        else if (serviceName === 'sms') {
            for (const contactInfo of xboxSubscribersList)
                new SMS(contactInfo.numberPhone).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: XBOX')
            for (const contactInfo of playstationList)
                new SMS(contactInfo.numberPhone).sendMessage('THE BEST CONSOLE EVER HAS COME TO OUR STORE: PLAYSTATION')
        }
    }
}

Even though everything was working fine, they realized that the code was so ugly, then they decided to isolate the part they think was repeating and isolate the message:

import { Email, Whatsapp, SMS } from '../services'

class SendMessageToWaitlisteners  {
    static createMessage = (consoleName) => `THE BEST CONSOLE EVER HAS COME TO OUR STORE: ${consoleName}`
    constructor(
            private readonly serviceName: string,
            private readonly xboxSubscribersList,
            private readonly playstationList
          ) {
        const xboxMessage = SendMessageToWaitlisteners.createMessage('XBOX')
        const playstatioMessage = SendMessageToWaitlisteners.createMessage('PLAYSTATION')
        for (const contactInfo of xboxSubscribersList) {
            if (serviceName === 'email')
                new Email(contactInfo.email).sendMessage(xboxMessage)
            else if (serviceName === 'whatsapp')
                new Whatsapp(contactInfo.numberPhone).sendMessage(xboxMessage)
            else if (serviceName === 'sms')
                new SMS(contactInfo.numberPhone).sendMessage(xboxMessage)
        }
        for (const contactInfo of playstationList) {
            if (serviceName === 'email')
                new Email(contactInfo.email).sendMessage(playstatioMessage)
            else if (serviceName === 'whatsapp')
                new Whatsapp(contactInfo.numberPhone).sendMessage(playstatioMessage)
            else if (serviceName === 'sms')
                new SMS(contactInfo.numberPhone).sendMessage(playstatioMessage)
        }
    }
}

You may be thinking the code now is better (at least compared to before), but NO!

Of course, we have a problem with repetition but the most evident problem in this code is COUPLING.

What if the business needs to send different messages for each service? For instance, with WhatsApp, I would like to use some emojis, so would I create another variable and use it?

What if the business needs to implement another service, like messaging through Messenger? Should I create another conditional and implement the service?

What if the business needs to update another software that is interested in this behavior? Like, posting into a business's social networks? Should we create another conditional?

OMG, so chaotic. 🤪

Observer Pattern

Taylor has come back from her vacation and went to her job. When she went there and started to work on code the team started being worried about her because they thought she would complain about code quality when would read. But she just says:

I know you guys tried your best with all constraints and context and I really appreciate it. Everything worked as expected, however, looking ahead, we need to improve this to help us in the future, especially because we probably will need to implement a lot of things in the future based on this behavior(Out-of-stock console arrived in-store). So, let's go guys, let's implement Observer Pattern.

The Observer Pattern is a Behavioral Design Pattern that allows an object (known as the "subject/observable/event/publisher") to publish changes to its state so that other objects (known as "observers/listeners/subscribers") can react accordingly.

Let's understand some concepts about the Observer pattern using our example below and cleaning up our code when it's possible:

Subject: This is an interface that declares a set of methods for managing subscribers.

In our example: Subject Interface

interface Subject {
    addObserver(observer: Observer): void;
    removeObserver(observer: Observer): void;
    notifyAll(): void;
}

Observer: This is an interface or abstract class representing any object that needs to be notified of changes by the subject.

In our example: Observer Interface

interface Observer{
    update(currentQuantityInStock:number):void;
}

ConcreteSubject: ConcreteSubject is a class that implements the Subject interface and contains the actual state or data that the observers are interested in. When this state changes, the observers need to be notified. In our case to simplify our example, we will just notifyAll when our state changes to positively.

In our example: PlaystationStockConcreteSubject and XboxStockConcreteSubject classes


class PlaystationStockConcreteSubject implements Subject {
    private readonly observers: Observer[]
    private _quantityInStock: number
    constructor() { }
    get quantityInStock(){
        return this._quantityInStock
    }
    set quantityInStock(value){
        this._quantityInStock = value
        if(value > 0) this.notifyAll()
    }
    addObserver(observer: Observer): void {
        this.observers.push(observer);
    }
    removeObserver(observer: Observer): void {
        const index = this.observers.indexOf(observer);
        if (index > -1) {
            this.observers.splice(index, 1);
        }
    }
    notifyAll(): void {
        for (let observer of this.observers) {
            observer.update(this.quantityInStock)
        }
    }
}
class XboxStockConcreteSubject implements Subject {
    private readonly observers: Observer[]
    private _quantityInStock: number
    constructor() { }
    get quantityInStock(){
        return this._quantityInStock
    }
    set quantityInStock(value){
        this._quantityInStock = value
        if(value > 0) this.notifyAll()
    }
    addObserver(observer: Observer): void {
        this.observers.push(observer);
    }
    removeObserver(observer: Observer): void {
        const index = this.observers.indexOf(observer);
        if (index > -1) {
            this.observers.splice(index, 1);
        }
    }
    notifyAll(): void {
        for (let observer of this.observers) {
            observer.update(this.quantityInStock)
        }
    }
}

ConcreteObserver: A class that implements the Observer. It will have a method to get updated data from the Subject.

To summarize things, let's assume that:

Xbox users only want to be notified by email and WhatsApp.
PlayStation users only by SMS.
The system wants to post on social networks if Xbox or PlayStation increases their stocks.

In our example: XboxEmailNotificator,XboxWhatsappNotificator,PlaystationSmsNotificator and SocialNetworkNotificator classes

class XboxEmailNotificator implements Observer{
    constructor(
            private readonly emailService,
            private readonly emailList:string[]
        ){}
    update(currentQuantityInStock: number): void {
        this.emailService.send(`Hello, this is an email to let you know about our Xbox stock, we have ${currentQuantityInStock} available!!`,this.emailList)
    }
}
class XboxWhatsappNotificator implements Observer{
    constructor(
        private readonly whatsappService,
        private readonly numbersPhone:string[]
    ){}
    update(currentQuantityInStock: number): void {
        this.whatsappService.send(`Hey buddy 😃, come on to our store there is a lot of ${currentQuantityInStock} xbox available!! 💁💁`,this.numbersPhone)
    }
}
class PlaystationSmsNotificator implements Observer{
    constructor(
        private readonly whatsappService,
        private readonly numbersPhone
    ){}
    update(currentQuantityInStock: number): void {
        this.whatsappService.send(`Hey!!! There is ${currentQuantityInStock} PLAYSTATIONS available!! 💁💁`,this.numbersPhone)
    }
}
class SocialNetworkNotificator implements Observer{
    constructor(
        private readonly facebookSDK
    ){}
    update(currentQuantityInStock: number): void {
        this.facebookSDK.send(`Stock Update! New consoles now available. Grab yours! 🚀 #Restocked`)
    }
}

And our client code may look like this:


//Fake data
const fakeEmails = ['iaan.123@gmail.com','another_guy@123xyz.com',"johndoe@johndoe.com"]
const fakeNumbers = ['+1999999999','+11231111111',"+167145349873648"]

//ConcreteSubjects
const xboxStockConcreteSubject = new XboxStockConcreteSubject()
const playstationStockConcreteSubject = new PlaystationStockConcreteSubject()

//ConcreteObservers
const xboxEmailNotificator = new XboxEmailNotificator(new EmailService(), fakeEmails)
const xboxWhatsappNotificator = new XboxWhatsappNotificator(new WhatsappService(), fakeNumbers)
const playstationSmsNotificator = new PlaystationSmsNotificator(new SmsService(), fakeNumbers)
const socialNetworkNotificator = new SocialNetworkNotificator(new FacebookSDK())

//Registering observers into subject
xboxStockConcreteSubject.addObserver(xboxEmailNotificator)
xboxStockConcreteSubject.addObserver(xboxWhatsappNotificator)
playstationStockConcreteSubject.addObserver(playstationSmsNotificator)

xboxStockConcreteSubject.addObserver(socialNetworkNotificator)
playstationStockConcreteSubject.addObserver(socialNetworkNotificator)

And when my state inside my concrete subjects is updated, so:


xboxStockConcreteSubject.quantityInStock = 9999
/**
 * Email Sent: Hello, this is an email to let you know about our Xbox stock, we have 9999 available!!
 * Whatsapp Sent: Hey buddy 😃, come on to our store there is a lot of 9999 xbox available!! 💁💁
 * Facebook Post Sent: Stock Update! New consoles now available. Grab yours! 🚀 #Restocked
 */

playstationStockConcreteSubject.quantityInStock = 25
/**
 * Sms Sent: Hey!!! There is 25 PLAYSTATIONS available!! 💁💁
 * Facebook Post Sent: Stock Update! New consoles now available. Grab yours! 🚀 #Restocked
 */

Then, if just need to create a new behavior in a system that will execute if the stock is updated, I just need to create a new class that implements Observer and register it into a specific ConcretClass (Like PlaystationStockConcreteSubject)

I can also register/remove an observer at any time, even at runtime.

Pros & Cons

Pros:

Decoupling: The Observer pattern promotes a decoupled design where subjects and observers can interact without being tightly linked.

- Single Responsibility Principle:

The Subject has the responsibility of managing its observers. It can attach, detach, and notify observers, but it doesn't concern itself with what these observers do with the information. This separation ensures that the Subject remains focused on its core task.
Each Observer has its own responsibility for how it reacts to the notifications from the Subject. One observer might send notifications to customers, another might post on social network, and more. By keeping these responsibilities separate, the Observer Pattern adheres to the SRP.

- Open Closed Principle: You can introduce new types of Subjects/Observers into the program without breaking existing client code, just implementing the contracts.

Dynamic Relationships: Observers can be added or removed at runtime, offering dynamic relationships.

Broadcast Communication: A single subject can notify multiple observers without knowing who or what those observers are.

Cons

Overhead: The pattern can introduce overengineering, especially if not many components need to be observed.

Randomly Update: The subscribers will be updated but in a random order.

Unexpected Updates: Observers might receive updates they didn't expect, leading to potential issues.

Memory Leaks: If observers aren't properly removed, it can lead to memory leaks.

Conclusion

Thanks for reading.

We learned in this article that the Observer pattern can promote a more modular and scalable architecture, making systems easier to extend and maintain without coupling components.

However, remember this quote: "Not every problem is a nail, so use your hammer wisely."

I'm so excited to write these articles because I'm challenging myself to organize my thoughts, improve my writing (English is not my first language), and help people who are interested in these kinds of subjects.

As always, your feedback, suggestions, and critiques are welcome.

I hope you enjoyed it and I hope to see you in the next article.

Bye.

References

Refactoring.guru - Observer
Observer pattern - Wikipedia
Você nunca mais vai conseguir ler um código da mesma forma... - Filipe Deschamps
DRY - Wikipedia
Observer - Unity

Design Patterns: Factory Method [PT-BR]

Iaan Mesquita — Sat, 19 Aug 2023 16:54:42 +0000

English version: https://dev.to/ianito/design-patterns-factory-method-22if

Olá,

Se você ainda não me conhece, eu me chamo Iaan Mesquita.

Atuo como engenheiro de software e hoje darei início a uma série de artigos que falam um pouco sobre a área de Engenharia de Software/Arquitetura de Software.

Mas antes, você provavelmente pode se perguntar: Por que os padrões de projeto são tão importantes? Bem, eles fornecem soluções para problemas comuns com os quais nós, como desenvolvedores, precisamos lidar. Assim, o uso de padrões de projeto podem tornar o software mais fácil de entender (embora nem sempre), estender e manter.

Recomendo começar essa série por este artigo, pois irei introduzir alguns conceitos que serão fundamentais para os próximos artigos. Para evitar repetições, aconselho que você se familiarize com esses conceitos básicos.

Nota: Nem sempre seguirei as práticas mais recomendadas ao explicar um padrão de design específico (já que meu objetivo é focar no conceito em questão). Todo feedback é bem-vindo, mas entenda essa limitação pois quero explicar os conceitos de uma forma que algum iniciante possa entender. Além disso, alguns termos não serão traduzidos pois eu acho que mais bagunça do que ajuda.

Também é interessante ter uma compreensão de Programação Orientada a Objetos (POO) e dos princípios SOLID.

Resumo

Readability vs Writability
Injeção de Dependência
Padrões Criacionais, Estruturais, e Comportamentais
Problema
Factory Method
Prós & Contras
Conclusão
Referências

Antes de começar a discutir os padrões de design, vamos dar uma olhada em alguns conceitos:

Readability vs Writability

Readability

Significa a facilidade com que um código pode ser lido e compreendido por outros desenvolvedores.

Writability

Significa a facilidade com que um código pode ser escrito. Isso não tem nada a ver com a velocidade de que você escreve um código. Podemos entender esse conceito pela facilidade de expressar nossas ideias como desenvolvedores. Se você já trabalhou com a linguagem C, pode entender esse conceito se lembrando da manipulação de strings e comparando-a com outra linguagem, tipo Javascript.

Esses dois conceitos são muito importantes no campo da engenharia de software (mas não exclusivamente). Em geral, você não criará coisas novas, mas aprimorará coisas que já existem e, para isso, a readability e writability podem afetar nosso software a longo prazo.

Se você pudesse escolher entre um software que pudesse ser lido/extendido com facilidade ou um software em que cada desenvolvedor decidisse seguir seus próprios padrões, qual você escolheria?

A menos que esteja tentando se desafiar, eu sei a resposta. xD

No entanto, isso não significa que todos os padrões comumente conhecidos ofereçam uma ótima writability ou readability. Às vezes, precisaremos priorizar um em detrimento do outro por motivos de melhor extensibilidade ou até mesmo, restrições específicas do projeto/equipe.

De qualquer forma, entender esses conceitos é crucial para discutir, decidir e aplicá-los quando necessário.

Injeção de dependência

A injeção de dependência (DI) é um padrão de design de software que define como os componentes ou objetos devem adquirir suas dependências. Em vez de um objeto criar suas próprias dependências (como instanciar dentro da implementação) ou usar instâncias globais, as dependências são "injetadas" no objeto, normalmente por meio de seu construtor, um método ou propriedades. Isso permite melhor flexibilidade para testes e manutenção no software.

Apesar de simples, discutiremos esse padrão de design no futuro.

Padrões criacionais, estruturais e comportamentais

Os padrões criacionais concentram-se em maneiras de instanciar objetos. Esses padrões oferecem várias técnicas, além do uso de construtores, para garantir a flexibilidade e a capacidade de manutenção.

Os padrões estruturais orientam a composição de objetos ou classes, visando à escalabilidade e à capacidade de manutenção.

Os padrões comportamentais tratam de como os objetos interagem e se comunicam, enfatizando as responsabilidades dos objetos e como eles se comunicam.

Porém hoje discutiremos o Método Fábrica (Factory Method) - (Padrão de Criação)

Problema

Imagine que você esteja criando um aplicativo para ajudar seu cliente a gerenciar suas contas do Instagram. Como você é uma startup, está validando suas ideias e o primeiro e único recurso que seu aplicativo tem é a capacidade de publicar no Instagram.

Mas agora seus clientes amaram seu aplicativo e estão sentindo falta de outras redes sociais, como X, Facebook, BlueSky e diversas outras, e você decidiu implementá-las.

Você ainda não sabe qual a API da rede social que irá implementar, mas sabe que é uma API.

No entanto, você sabe que cada rede social tem seu próprio método para postar nelas e também tem diferentes dependências e validações mas você sabe que o comportamento é o mesmo: postar em uma rede social.

Você concorda comigo que todos os lugares dentro do seu aplicativo que precisam ter essa funcionalidade de postar em uma rede social não precisa saber sobre a implementação? Basta funcionar como esperado e publicar nelas?

Para esse exemplo, vamos supor também que você esteja desenvolvendo seu sistema usando injeção de dependência, passando dependências pelo construtor. Um exemplo disso seria:

new TwitterAPI(messageValidator,twitterSDK);
//or and
new FacebookAPI(messageValidator,userIdHash,facebookSDK);
//or and
new InstagramAPI(instagramSDK);

Não pense muito nos detalhes, apenas capte a ideia principal: Estamos passando algumas dependências que a classe precisa através do construtor.

Acontece que se precisarmos usar a FacebookAPI/TwitterAPI em muitos lugares, toda vez que nós quisermos usar os métodos da classe, precisaremos primeiro instanciá-la e com isso também passar suas dependências.

Mas não só isso, o que acontece se o Facebook decidir que não permitirá que você publique na plataforma deles antes de confirmar que você não é um robô e você precisa fazer essa validação por você mesmo? Como resultado, você precisará validar isso antes de enviar, e agora você tem muitos lugares para fazer essa alteração porque uma coisa mudou na forma de como se comunicar com a API do Facebook.

Portanto, uma solução para esse problema é usar Factories.

Método Fábrica (Factory Method)

O Factory Method é um padrão de design de criação que fornece uma interface para a criação de objetos, mas permite que as subclasses alterem o tipo do objeto que será criado, e os objetos retornados por um Factory Method são geralmente chamados de products.

A ideia principal do Factory Method é delegar a implementação do código de criação às suas subclasses ou classes que a implementam.

No entanto, há uma limitação: as subclasses podem retornar diferentes tipos de Product somente se esses Products tiverem uma classe ou interface base comum (APIIntegration).

Além disso, o Factory Method na classe base deve ter seu tipo de retorno (APIIntegration) declarado como essa interface.

Vamos entender alguns conceitos sobre o Factory Method usando o exemplo abaixo:

Product: É uma interface ou classe abstrata que define o tipo de objetos que o Factory Method criará.

Em nosso exemplo: Interface APIIntegration

Creator: Essa classe declara o próprio Factory Method. Esse método retorna um objeto do tipo do Product. Em algumas implementações, o Creator pode ser uma interface, uma classe abstrata ou até mesmo uma classe concreta.

Em nosso exemplo: Interface APIFactory com métodos createApi e retorna um Product do tipo APIIntegration

ConcreteCreator: Uma classe que implementa ou estende o Creator e sobrescreve o método factory para retornar uma instância de um ConcreteProduct específico.

Em nosso exemplo: TwitterAPIFactory, FacebookAPIFactory e InstagramAPIFactory

ConcreteProduct: Essa é uma implementação específica do Product. É isso que o ConcreteCreator instanciará e retornará.

Em nosso exemplo: TwitterAPI, FacebookAPI, InstagramAPI

Então, vamos dar uma olhada no código:

Não leve muito a sério os detalhes de como me conectei ao APIS ou à sintaxe, todos os exemplos são fakes e não se baseiam na documentação oficial. Apenas absorva a ideia do que estou fazendo.

As dependências das classes do ConcreteProduct são passadas por meio do construtor. (DI)

Product

interface APIIntegration {
  post(message: string): void;
}

Creator

export interface APIFactory {
    createAPI(): APIIntegration;
  }

ConcreteProduct

class TwitterAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
    // this.messageValidator = messageValidator
    // and so on
  constructor(private readonly messageValidator: MessageValidator, private readonly  twitterSdk: TwitterSDK) {}
  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    if (!this.messageValidator.validate(message))
      throw new Error("invalid validation");
    if (!this.twitterSdk.isConnected) throw new Error("connection refused");
    this.twitterSdk.post(message);
    console.log(`Posting on twitter: ${message}`);
  }
}

class FacebookAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
    // this.messageValidator = messageValidator
    // and so on
  constructor(
    private readonly messageValidator: MessageValidator,
    private readonly userIdHash: string,
    private readonly facebookSDK: FacebookSDK
  ) {} //New param (userIdHash)
  post(message: string) {
     // A code to make it possible(Implementation)
    // Fake code below
    if (!this.messageValidator.validate(message))
      throw new Error("invalid validation");
    if (!this.facebookSDK.isConnected) throw new Error("connection refused");
    if (!this.facebookSDK.findUser(userIdHash))
      throw new Error("user not found");
    this.facebookSDK.post(message);
    console.log(`Posting on facebook: ${message}`);
  }
}

class InstagramAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
  constructor(private readonly instagramSDK: InstagramSDK) {} //New params (userIdHash)
  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    this.instagramSDK.post(message);
    console.log(`Posting on instagram: ${message}`);
  }
}

ConcreteCreator

class TwitterAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const messageValidator = new MessageValidator()
    const twitterSDK = new TwitterSDK()
    return new TwitterAPI(messageValidator,twitterSDK);
  }
}

class FacebookAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const messageValidator = new MessageValidator()
    const facebookSDK = new FacebookSDK()
    const userIdHash = "123"
    return new FacebookAPI(messageValidator,userIdHash,facebookSDK);
  }
}

class InstagramAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const instagramSDK = new InstagramSDK()
    return new InstagramAPI(instagramSDK);
  }
}

Client code

const allSocialNetworks:APIFactory[] = [new InstagramAPIFactory(),new FacebookAPIFactory(),new TwitterAPIFactory()];
for (const api of allSocialNetworks) {
    const socialNetworkAPI = api.createAPI()
    socialNetworkAPI.post('Hello Followers')
}

Com esse padrão de design, se eu precisar modificar as dependências ou até mesmo atualizar os pacotes que o Facebook, o Twitter ou o Instagram usam, só preciso ajustar meu ConcreteCreator e/ou ConcreteProduct, desde que eu respeite meu contrato APIIntegration(Product) e APIFactory(Creator).

Qualquer parte do meu código em que eu utilize minha API permanece inalterada e não é afetada por essas mudanças. Isso isola os possíveis bugs e reduz os locais onde o código precisa ser atualizado, diminuindo as chances de bugs.

Se eu também decidir integrar outra rede social, como o Threads, é simples, basta que eu crie um ConcreteProduct e ConcreteFactory específicos. Depois, posso chamá-la no código, sem precisar fazer mudanças bruscas alterando o que já existe.

class ThreadsAPI implements APIIntegration {
  constructor(private readonly threadsSDK: ThreadsSDK) {}

  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    this.threadsSDK.post(message);
    console.log(`Posting on Threads: ${message}`);
  }
}

class ThreadsAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const threadsSDK = new ThreadsSDK();
    return new ThreadsAPI(threadsSDK);
  }
}

E se eu também precisar criar testes para testar esse comportamento, eu não preciso usar uma implemetação real. Posso criar um ConcreteProduct e ConcreteFactory específicos que simulem esse comportamento.

Alguns pontos sobre o Factory Method

Quando falamos de design de software, não se trata apenas de fazer o código funcionar. Trata-se também de garantir que o código possa evoluir e precisamos ter em mente que tudo muda.

A tecnologia de hoje pode se tornar obsoleta amanhã. (Um salve pra galera do java escripto)

Portanto, nosso código precisa ser flexível o suficiente para acomodar essas mudanças sem ter de criar tudo novamente.

O Factory Method Pattern é bom nesses cenários:

Abstração: Ele fornece um ponto em comum com o código de diversos lugares em um só e o processo de instanciação do objeto. Essa abstração garante que, mesmo que a lógica de criação se torne complexa no futuro, ela não afetará outras partes do aplicativo.

Extensibilidade: Deseja adicionar outra rede socia ao seu aplicativo? Com o Factory Method, você pode introduzir sem esforço um novo ConcreteProduct (como uma nova integração de API) sem alterar muito do código existente.

Manutenibilidade: Como mencionado anteriormente, as alterações são localizadas. Se a API de uma determinada plataforma for alterada, só precisaremos modificar sua respectiva Factory e Product, deixando o restante do aplicativo intocado.

Esse padrão, embora não seja uma solução mágica para todos os problemas, oferece uma boa abordagem para a criação de objetos. Ele encapsula as complexidades e fornece uma estrutura clara, tornando o código mais compreensível e menos propenso a erros.

Prós e contras

Como qualquer ferramenta ou abordagem, o Factory Method tem suas vantagens e desvantagens:

Prós

Você evita o acoplamento forte entre a criação(creators) e a implementação(Concrete Products).
Single Responsability: É possível deixar a reponsabilidade de criação do Product em apenas um lugar, o que facilita a manutenção do código.
Open/Closed Principle: Você pode introduzir novos tipos de Products no programa sem quebrar o código do cliente existente.

Contras

O código pode se tornar mais complicado, pois você precisa introduzir muitas subclasses novas para implementar o padrão. O melhor cenário é quando você está introduzindo o padrão em uma hierarquia existente de classes de criadores.
Se a sua classe não precisar de muitas dependências, esse padrão pode ser over-engineering.
Se as dependência do aplicativo não mudam com frequência, o Factory Method poderá apenas aumentar a base de código sem agregar valor real. A otimização prematura é a raiz de todo o mal.

Conclusão

No software, as coisas mudam rapidamente. Portanto, precisamos de maneiras de mudar nossos aplicativos sem começar do zero.

O Factory Method nos ajuda a fazer isso. É como ter pedaços de códigos que podem ser facilmente trocados e substituídos conforme necessário.

Isso simplifica a adição de novas coisas ou a alteração de partes do nosso aplicativo.

No entanto, é importante entender os prós e os contras.

Sempre priorize a simplicidade e a clareza e use padrões onde eles realmente agregam valor.

Muito obrigado por ler até aqui :)

Sinta-se convidado a participar com dúvidas, críticas e sugestões.

Em nosso próximo artigo, discutiremos mais um pouco sobre outro tópico relacionado a engenharia de software.

Até mais :)

Referências

Factory Method: Simplifying Object Instantiation

Iaan Mesquita — Sat, 19 Aug 2023 16:54:28 +0000

Portuguese version: https://dev.to/ianito/design-patterns-factory-method-pt-br-21a3

Hi there,

If you don't know me, my name is Iaan Mesquita.

I'm a software engineer, and today I'll start a series of articles that talk a little bit about the Software Engineering/Software Architecture field.

But why are design patterns so important? Well, they provide solutions for common problems that we, as software engineers, need to deal. Using design patterns can make software easier to understand (though not always), extend, and maintain.

I recommend starting with this article, as it introduces concepts that will be foundational for the upcoming ones. To avoid redundancy, I advise familiarizing yourself with these basics.

Note: I won't always follow best practices when explaining a specific design pattern (since my goal is to focus on the concept at hand), please consider if your suggestions would simplify things for those unfamiliar with patterns. All feedback is welcome.

And also, it's good to have an understanding of Object-Oriented Programming (OOP) and SOLID principles.

Summary

Readability vs Writability
Dependecy Injection
Creational, Structural, and Behavioral Patterns
Problem
Factory Method
Pros & Cons
Conclusion
References

Before start discussing Design Patterns, let's take a look at some concepts:

Readability vs Writability

Readability

It means the ease with which a code can be read and understood by other developers.

Writability

It means the ease with which a code can be written. This is nothing about the velocity of typing, we can understand this concept by the easiness of expressing our ideas as a software engineer. If you ever worked with C language, you can understand this concept by remembering string manipulation there and compare with another language.

These two concepts are so important in the Software Engineering field (not only). In general, you won't create new things but enhance things that already exist and for that, readability and writability can affect our software in the long term.

If you could choose between software that you can read/write with facility or software with every developer decided to follow your own patterns, what do you will chose?

Unless you are trying to challenge yourself, I know the answer. xD

However, this doesn't imply that every common pattern known offers optimal writability or readability. At times, we might have to prioritize one over the other for reasons like enhanced extensibility or specific project/team constraints.

Otherwise understanding these concepts is crucial when deciding when and how to apply them.

Dependency Injection

Dependency Injection (DI) is a software design pattern that deals with how components or objects acquire their dependencies. Instead of an object creating its own dependencies (like instantiating your dependencies) or using global instances, dependencies are "injected" into the object, typically through its constructor, a method, or properties. This allows for greater flexibility, testability, and maintainability in software design.

We can discuss this pattern in the future.

Creational, Structural, and Behavioral Patterns

Creational Patterns focus on optimal ways to instantiate objects. These patterns offer various techniques, besides using constructors, to ensure flexibility and maintability.

Structural Patterns guide the composition of objects or classes, aiming for scalability and maintainability.

Behavioral Patterns address how objects interact and communicate, emphasizing objects' responsibilities and their collaboration.

Today we will discuss Factory Method - (Creational Pattern)

Problem

Imagine that you’re creating an application to help your customer to manage their Instagram accounts. As well as you are a startup, you are validating your ideas and the first and only feature that your app has is the ability to post on Instagram.

Now your customers loved your application and they are missing other social networks like X, Facebook, BlueSky, and whatever and you decided to implement them. I don't know yet which social api I'm going to use, but I know it's an API.

However, you know that every social network has its own method way to post into them, with different dependencies and validations for example, but you know the behavior is the same: Post inside a social network.

Are you agree with me that every place inside your application that you need to post inside a social network, doesn't need to know about implementation? Just work as expected and post inside a social network?

For this instance, let's assume that you are designing your application using Dependency Injection passing dependencies through the constructor, you would need to inject them into the constructor, like:

new TwitterAPI(messageValidator,twitterSDK);
//or and
new FacebookAPI(messageValidator,userIdHash,facebookSDK);
//or and
new InstagramAPI(instagramSDK);

Don't think so much about details, just catch the main idea, I'm passing some dependencies that my class needs.

Let's imagine too that I'll need to use FacebookAPI/TwitterAPI in a lot of places, and every time I wanted to use methods from class we first need to instantiate it and pass its dependencies through the constructor.

But not only this, what happens if Facebook decided that they won't let you post inside a platform before you confirm that you're not a robot? As a result, you will need to validate this before sending, and now you have a lot of places to make this change because one thing changed in the way that Facebook APIs communicate.

So, one solution to this problem is using Factories.

Factory Method

The Factory Method is a creational design pattern that provides an interface for creating objects but allows subclasses to change the type of an object that will be created and objects returned by a factory method are often referred to as products.

The main idea of the Factory Method is to delegate the implementation of the creation code to its subclasses or classes that implement it.

But there is a limitation though: subclasses may return different types of products only if these products have a common base class or interface(APIIntegration). Also, the factory method in the base class should have its return type(APIIntegration) declared as this interface.

Let's understand some concepts about Factory Method using our example below:

Product: This is an interface or abstract class defining the type of objects the factory method will create.

In our example: Interface APIIntegration

Creator: This class declares the factory method itself. This method returns an object of type Product. In some implementations, the Creator might be an interface, an abstract class, or even a concrete class.

In our example: Interface APIFactory with createApi methods and return a product of type APIImplementation

ConcreteCreator: A class that implements or extends the Creator and overrides the factory method to return an instance of a specific ConcreteProduct.

In our example: TwitterAPIFactory, FacebookAPIFactory, and InstagramAPIFactory

ConcreteProduct: This is a specific implementation of the Product. This is what the ConcreteCreator will instantiate and return.

In our example: TwitterAPI, FacebookAPI, InstagramAPI

So, let's see the code:

Don't take the details of how I connected to APIS too seriously or syntax, all the examples are fake and not based on the main documentation. Just absorb the idea.

The dependencies of the ConcreteProduct's classes are passed through the constructor. (DI)

Product

interface APIIntegration {
  post(message: string): void;
}

Creator

export interface APIFactory {
    createAPI(): APIIntegration;
  }

ConcreteProduct

class TwitterAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
    // this.messageValidator = messageValidator
    // and so on
  constructor(private readonly messageValidator: MessageValidator, private readonly  twitterSdk: TwitterSDK) {}
  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    if (!this.messageValidator.validate(message))
      throw new Error("invalid validation");
    if (!this.twitterSdk.isConnected) throw new Error("connection refused");
    this.twitterSdk.post(message);
    console.log(`Posting on twitter: ${message}`);
  }
}

class FacebookAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
    // this.messageValidator = messageValidator
    // and so on
  constructor(
    private readonly messageValidator: MessageValidator,
    private readonly userIdHash: string,
    private readonly facebookSDK: FacebookSDK
  ) {} //New param (userIdHash)
  post(message: string) {
     // A code to make it possible(Implementation)
    // Fake code below
    if (!this.messageValidator.validate(message))
      throw new Error("invalid validation");
    if (!this.facebookSDK.isConnected) throw new Error("connection refused");
    if (!this.facebookSDK.findUser(userIdHash))
      throw new Error("user not found");
    this.facebookSDK.post(message);
    console.log(`Posting on facebook: ${message}`);
  }
}

class InstagramAPI implements APIIntegration {
    // Private and readonly is the same as initializing the property through constructor method
  constructor(private readonly instagramSDK: InstagramSDK) {} //New params (userIdHash)
  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    this.instagramSDK.post(message);
    console.log(`Posting on instagram: ${message}`);
  }
}

ConcreteCreator

class TwitterAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const messageValidator = new MessageValidator()
    const twitterSDK = new TwitterSDK()
    return new TwitterAPI(messageValidator,twitterSDK);
  }
}

class FacebookAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const messageValidator = new MessageValidator()
    const facebookSDK = new FacebookSDK()
    const userIdHash = "123"
    return new FacebookAPI(messageValidator,userIdHash,facebookSDK);
  }
}

class InstagramAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const instagramSDK = new InstagramSDK()
    return new InstagramAPI(instagramSDK);
  }
}

Client code

const allSocialNetworks:APIFactory[] = [new InstagramAPIFactory(),new FacebookAPIFactory(),new TwitterAPIFactory()];
for (const api of allSocialNetworks) {
    const socialNetworkAPI = api.createAPI()
    socialNetworkAPI.post('Hello Followers')
}

With this design pattern, if I need to modify the dependencies or even update the packages that Facebook, Twitter, or Instagram use, I just need to adjust my ConcreteCreator and/or ConcreteProduct as long as I respect my contract APIIntegration(Product) and APIFactory(Creator).

Anywhere in my code where I utilize my API remains unchanged and unaffected by these shifts. This isolates potential sources of errors and minimizes the areas of code we must update, decreasing the chances of introducing bugs.

If I ever decide to integrate another social network, like Threads, it's as simple as crafting its specific ConcreteProduct and ConcreteFactory. Then, I can call it within my client code, without disrupting the existing setup.

class ThreadsAPI implements APIIntegration {
  constructor(private readonly threadsSDK: ThreadsSDK) {}

  post(message: string) {
    // A code to make it possible(Implementation)
    // Fake code below
    this.threadsSDK.post(message);
    console.log(`Posting on Threads: ${message}`);
  }
}

class ThreadsAPIFactory implements APIFactory {
  createAPI(): APIIntegration {
    const threadsSDK = new ThreadsSDK();
    return new ThreadsAPI(threadsSDK);
  }
}

And if I also need to create tests to test this behavior, I don't need to use a real implementation. I can create a specific ConcreteProduct and ConcreteFactory that simulate this behavior.

Some points about Factory Method

When we talk about software design, it's not just about making the code work. It's also about ensuring that the code can evolve and we need to have in mind that everything changes. Today's technology might be obsolete tomorrow.

Therefore, our code needs to be flexible enough to accommodate these changes without having to create everything again.

The Factory Method Pattern is good in these scenarios:

Abstraction: It provides a buffer between the client code and the object instantiation process. This abstraction ensures that even if the creation logic becomes complex in the future, it won't ripple and affect other parts of the application.

Extensibility: Want to add another social media platform to your application? With the Factory Method, you can effortlessly introduce a new ConcreteProduct (like a new API integration) without changing much of your existing code.

Maintainability: As mentioned earlier, changes are localized. If the API of a particular platform changes, we only have to modify its respective factory and product, leaving the rest of the application untouched.

This pattern, while not a silver bullet for all problems, offers a good approach to object creation. It encapsulates the complexities and provides a clear structure, making the code more understandable and less prone to errors.

Pros and Cons

Like any tool or approach, the Factory Method Pattern has its advantages and disadvantages:

Pros

You avoid tight coupling between the creator and the concrete products.
Single Responsibility Principle. You can move the product creation code into one place in the program, making the code easier to support.
Open/Closed Principle. You can introduce new types of products into the program without breaking existing client code.

Cons

The code may become more complicated since you need to introduce a lot of new subclasses to implement the pattern. The best-case scenario is when you’re introducing the pattern into an existing hierarchy of creator classes.
If your class doesn't need a lot of dependencies this pattern can add over-engineering.
If the application's dependency requirements are not expected to change frequently, then the Factory Method Pattern may just increase the codebase without adding real value. (Over-engineering)

Conclusion

In software, things change fast. So, we need ways to update our apps without starting from scratch.

The Factory Method Pattern helps us do this. It's like having building blocks we can easily swap out and replace as needed.

It makes adding new things or changing parts of our app simpler.

However, it's important to understand the pros and cons.

Always prioritize simplicity and clarity, and employ patterns where they genuinely add value.

Thank you for reading, and in our next article we will discuss a little bit about another design pattern.

Feel free to comment, make suggestions and criticize.

See you :)

References

How did I discover a security vulnerability in a system of my university

Iaan Mesquita — Tue, 17 May 2022 21:54:51 +0000

Portuguese version: Como eu descobri uma falha de segurança em um sistema na minha universidade

Hi everybody, today i will tell you how did I discover a security vulnerability in a system of my university, what i did i do in next, how we can avoid this and my conclusions.

I want to be clear that my objectives weren't stain company image, university or developers, but only can contribute with system security and also contribute for information security scenario in Brazil.

How did I discover vulnerability ?

Well, at the time we were in the pandemic when classes were mostly online and that's why the use of online system was most frequent than in person. Then, in this class was introduced for us a system (already utilized for a some time by university) and that we should utilised to post exercicies and follow our grade. Being a new system, I was curious to see what was traffing between the application and my network and I have started to look for something interestant.

So, I founded two requests interestant:

One that returned my personal data
Another that returned some numbers of my credit card, card flag, expiration date and etc

But Iaan, we only found two requests that show our self data, and?

You're right, that's why i decided to test if that routes was allow made if I haven't a token or a valid token.

Did not work. :(

It was then i thought, and if my token is valid but my request has a ID different of my user id?

And... THATS WORKED!!

I made a request using the curl command and changing my id what which was a parameter in the route.

Same happened with route that return some info about my credit card.

This happens because the application back-end only verified if my token is valid to make the request but not verify if the id was requesting really belonged to my user.

Suppose my id is 21 and I have be authenticate in application, so the route to show my personal data were something like:

http://myapi.com.br/personal-data?id=21

Then, I was already authenticate and my token was valid, if i changed my id in the request to 22, I could get all personal data of id 22.

Ok, vulnerability found and now?

What did I do after finding the vulnerability?

I started documenting all I have done to discover this vulnerability to report to those responsibles.
I created abstract of vulnerability .
In this document I described a abstract of vulnerability, how to execute, possible solution, a tiny script to prove the vulnerability (Proof-of-concept) and the source code.

PoC:https://www.youtube.com/watch?v=tU1qOoPhwtg

I didn't know responsible's email of application so i asked for help to my professor and he helped me to send document to them.
In the next day, I receveid a response email:

(Google translate bellow xD)

Dear,
We hope to find you all well.
We have received your notification regarding a security flaw in one of our applications and we would like to inform you that we have immediately submitted this notification to our engineering team for analysis and correction.
After analysis, it was found that in fact there was a vulnerability that would allow the consultation of other people's registration data, only when in possession of a valid token. The token in this context is similar to a key, generated from the successful authentication of a student after entering their username and personal password. People without this token, that is, without a valid login, would not be able to access said personal data.

All necessary corrections and validations have been implemented so that this scenario no longer occurs.
Regarding credit card data, it is important to note that we do not store any critical or sensitive student credit card data. For the avoidance of doubt, below is a brief explanation of how credit card use works in our solutions:

When a student wants to make any payment via credit card, when entering their card information, this data is sent directly to the Banking Institution through a process called "Transparent Checkout" where the data is being sent directly to the bank within of our platform. In other words, it is as if the student were on the bank's website while still on our platform. This communication with the bank is carried out using a secure and encrypted connection, in addition to all the latest security protocols available for the internet. At no time do we collect any information transacted in this transaction. After completing the payment, the Banking Institution returns us whether it was successful or not, and, when successful, sends us a token that identifies that student's card with the bank. Accompanied by this token comes the masked number of the card and its brand, so that if the student needs to make another payment through the platform, he can do it more easily and quickly. This token by itself has no validity because, in the event of a new payment, the insertion of the verification code printed on the credit card and a public and a private key created between the bank and our system will be required for the transaction be validated, reinforcing that the entire transaction will be carried out in a secure environment provided by the Banking Institution.

We highly value the quality and integrity of the services we provide. Our innovation cycle includes reviewing services already built to measure performance and safety criteria. We are deeply sorry that this failure has gone unnoticed. Therefore, we carefully check all the points that were raised and these have already been corrected. We also emphasize our commitment to follow and keep an eye on all
current legislation regarding information security, in particular the Law
no. 13.709/18 (General Law for the Protection of Personal Data - "LGPD") and the Law
12.965/2014 (Marco Civil da Internet).

On all our platforms, our privacy policy is publicly available, which explains how personal data is treated in our solutions. Questions related to XX's Privacy Policy or any other questions related to the topic of security and protection of Personal Data, can be sent via the support contact email
Certain of our understanding, we make ourselves available for any clarifications. Yours sincerely,

Then, I checked if the vulnerability was fixed.

What we can learning about this?

Never trust the user, remember that any validation you do on the client side is susceptible to changes by the user. Validate everything on the backend that needs validation and run tests to make sure your result is as expected. Could we change the id from int to a UUID? It depends, if it's just for that, it's not a good idea because a validation would already make it impossible and only with this change you would be solving only part of the problem. You have to understand the trade-offs in adopting this technique. (I recommend the article Are you going to use UUID as PK instead of Int/BigInt in your database? Think again..., it has some pretty good insights)

Conclusion

Thanks for reading, this is one of my posts that is part of my new way of learning using learn in public.

If you're interested, you can check out what it is: https://www.swyx.io/learn-in-public/

I intend to continue doing this and I already have the next post prepared.

Spoiler: This one also involved my university

PS: I'm learning English too, feel free to comment on my grammatical errors.

Como eu descobri uma falha de segurança em um sistema na minha universidade

Iaan Mesquita — Tue, 17 May 2022 21:54:36 +0000

English version: How did I discover a security vulnerability in a system of my university

Eai galera, então hoje eu vou contar como eu descobri uma falha de segurança em um dos sistemas que minha universidade utiliza, o que eu fiz logo em seguida, como podemos evitar e minhas conclusões.

Quero deixar claro que meu objetivo não é manchar a imagem da empresa, universidade ou dos desenvolvedores, mas sim poder contribuir com a segurança do sistema bem como também contribuir para o cenário de Segurança da Informação no país.

Como eu descobri a falha?

Bom, na época estavamos na pandemia em que as aulas em sua maioria eram todas onlines e por isso o uso de sistemas onlines eram mais frequentes do que no presencial. Então, nessa aula foi nos apresentados um sistema (já utilizado a algum tempo pela universidade) e que deveriamos utilizar para postar atividades e acompanhar notas. Sendo um sistema novo, tive a curiosidade de ver o que estava trafegando nas requisições feitas pelo sistema e comecei a procurar requisições que fossem interessantes.

Então, encontrei duas requisições interessantes.

Uma que me retornava meus dados cadastrais
Outra que me retornava alguns números do meu cartão de crédito, data de validade, bandeira e etc.

Mas Iaan, até agora só encontramos duas rotas que mostram nossos próprios dados, e dai?

Você tem razão, por isso eu decidi testar se essas rotas permitiriam ser feitas se eu não tivesse um token ou se meu token fosse inválido, e...

Não deu em nada. :(

Foi então que eu pensei, e se meu token for válido mas minha requisição tiver um id diferente do meu, ou seja, de outro usuário?

E... funcionou! :D

Fiz uma requisição utilizando o comando curl e mudando meu id que era um paramêtro na rota.

O mesmo acontecia na rota que mostrava informações dos cartões de créditos.

Isso acontece pois o back-end da aplicação apenas verificava se o token era válido para fazer a requisição mas não verificava se o id que eu estava solicitando realmente pertenciam a meu usuário.

Suponhamos que meu id seja o 21 e que eu esteja autenticado na aplicação, então a rota para mostrar meus dados pessoais poderia ser algo assim:

http://apidosistema.com.br/dados-pessoais?id=21

Então, como eu estava autenticado e meu token era válido, se eu mudasse o id da requisição para 22, eu conseguia obter dados do usuário com esse id.

http://apidosistema.com.br/dados-pessoais?id=22

Ok, falha encontrada e agora?

O que eu fiz logo após encontrar a falha?

Comecei a documentar o que eu tinha descoberto para reportar aos responsáveis.
Criei um documento em que eu dava um resumo da falha que tinha acabado de descobrir.
Nesse documento descrevi um resumo da falha, gravidade, como executar, possível solução, um script simples que mostrava a falha (Proof-of-concept) e o código fonte do mesmo.

PoC:https://www.youtube.com/watch?v=tU1qOoPhwtg

Como não sabia o email dos responsáveis pela plataforma, entrei em contato com meu professor que me ajudou a enviar o documento para eles.
No dia seguinte, recebi um email com uma resposta da plataforma.

Prezados,
Esperamos encontrar todos bem.
Recebemos a sua notificação a respeito de uma falha de segurança em uma de nossas aplicações e gostaríamos de informar que de imediato, submetemos essa notificação ao nosso time de engenharia para análise e devidas correções.
Após análise ficou constatado que de fato existia uma vulnerabilidade que permitiria a consulta dos dados cadastrais de outras pessoas, somente quando em posse de um token válido. O token nesse contexto é semelhante a uma chave, gerada a partir da autenticação bem-sucedida de um aluno no após informar seu usuário e sua senha pessoal. Pessoas sem esse token, ou seja, sem um login válido, não conseguiriam acesso aos referidos dados pessoais.

Todas as correções e validações necessárias foram implementadas para que esse cenário não ocorra mais.
Com relação aos dados de cartão de crédito é importante destacar que não armazenamos nenhum dado crucial ou sigiloso do cartão de crédito do aluno. A fim de não restarem dúvidas, abaixo segue uma breve explicação de como funciona o uso do cartão de crédito nas nossas soluções:

Quando um aluno deseja realizar qualquer pagamento via cartão de crédito, ao inserir as informações do seu cartão, esses dados são enviados diretamente à Instituição Bancária através de um processo chamado de “Checkout transparente” onde os dados estão sendo enviados diretamente ao banco de dentro da nossa plataforma. Em outras palavras, é como se o aluno estivesse no site do banco estando ainda na nossa plataforma. Essa comunicação com o banco é realizada utilizando uma conexão segura e criptografa, além de todos os mais recentes protocolos de segurança disponíveis para internet. Em nenhum momento nós coletamos quaisquer informações transacionadas nessa operação. Após a finalização do pagamento a Instituição Bancária nos retorna se ela foi bemsucedida ou não, e, quando bem-sucedida, nos envia um token que identifica aquele cartão do aluno junto ao banco. Acompanhado desse token vem o número mascarado do cartão e sua bandeira, para que caso o aluno precise realizar outro pagamento pela plataforma, ele consiga fazê-lo de forma mais fácil e rápida. Esse token por si só não tem nenhuma validade pois, na eventualidade de um novo pagamento, será exigido a inserção do código de verificação impresso no cartão de crédito e de uma chave pública e outra privada criadas entre o banco e nosso sistema para que a transação seja validada, reforçando que toda a transação será realizada em um ambiente seguro fornecido pela Instituição Bancária.

Prezamos muito pela qualidade e integridade dos serviços que prestamos. Nosso ciclo de inovação contempla revistar serviços já construídos para mensurar critérios de desempenho e segurança. Sentimos profundamente que essa falha tenha passado despercebida. Por isso, verificamos com muita cautela todos os pontos que foram levantados e estes já se encontram corrigidos. Ressaltamos também nosso compromisso em seguir e mantermos atentos a toda
a legislação vigente referente a segurança da informação, em destaque para a Lei
nº. 13.709/18 (Lei Geral de Proteção de Dados pessoais - "LGPD") e a Lei
12.965/2014 (Marco Civil da Internet).

Em todas as nossas plataformas, está disponível, de forma pública, a nossa política de privacidade que explica como os dados pessoais são tratados nas nossas soluções. Questionamentos relacionados à Política de Privacidade da XX ou quaisquer outras dúvidas relacionadas ao tema de segurança e proteção dos Dados Pessoais, podem ser enviadas através do e-mail de contato com o suporte
Certo de nossa compreensão, nos colocamos à disposição para quaisquer esclarecimentos. Atenciosamente,

Em seguida, eu conferi se a falha tinha sido corrigida:

O que podemos aprender disso?

Nunca confie no usuário, lembre-se que qualquer validação que você faça no lado do cliente é suceptível a mudanças pelo usuário. Valide tudo no back-end que seja necessário validação e faça testes para que se certifique que o seu resultado seja o esperado. Poderíamos trocar o id de int para um UUID? Depende, se for só pra isso, não é uma boa ideia pois uma validação ja impossibilitaria isso e somente com essa mudança você estaria resolvendo apenas uma parte do problema. Você tem que entender os trade-offs ao se adotar essa técnica. (Recomendo o artigo Pretende usar UUID como PK em vez de Int/BigInt no seu banco de dados? Pense novamente..., tem alguns insights muito bom)

Conclusão

Obrigado por ler até aqui, esse é um dos meus posts que faz parte do meu novo jeito de aprender usando learn in public.

Caso tenha interesse, você pode dar uma conferida sobre o que é isso: https://www.swyx.io/learn-in-public/

Pretendo continuar fazendo isso e já tenho o próximo post preparado.

Spoiler: Esse também envolveu minha universidade

How to emulate iOS on Linux with Docker

Iaan Mesquita — Wed, 29 Dec 2021 01:06:06 +0000

NOTE

I am currently available for opportunities as a Full-Stack Engineer or Back-End Engineer. If you know of any open positions, please, feel free to contact me on LinkedIn Iaan Mesquita :).

After several unsuccessful attempts, I was finally able to virtualize a macOS to run tests on an iOS app I was working on.

But before proceeding, it is necessary to know that this is not a stable solution and has several performance issues, however, for my purpose I managed to do what I wanted.

We'll use QEMU to emulate a mac and inside it we'll use xCode to emulate an iOS. That process not will be lightweight.

The repository on github of Docker OSX has an explanation of how to use an iPhone via usb instead of emulating, but I don't have iPhone. xD

Summary

What is Docker OSX
Hardware Specifications
Installation
Running a app with React Native
Running a app with Cordova
Creating a connection of folders over SSH
Final considerations

What is Docker OSX

The Docker OSX is a docker image that uses QEMU so that we can emulate an operating system.

Read more: What is Docker?

Hardware Specifications

My computer's specs are considered OK to do this, however, I still managed to notice some lags while using Docker OSX + xCode + Visual Studio Code + Dev Server. (I was even able to heat my room with that much stuff)

OS: Manjaro Linux x86_64
Kernel: 4.19.220-1-MANJARO
Shell: zsh 5.8
Resolution: 1440x900
DE: GNOME 41.2
WM: Mutter
WM Theme: Orchis-orange-compact
Icons: Win11-purple-dark [GTK2/3]
Terminal: gnome-terminal
CPU: Intel i7-3770 (8) @ 3.900GHz
GPU: NVIDIA GeForce GTX 1050 Ti
Memory: 4105MiB / 15985MiB
SSD: Crucial BX500 240gb (Highly recommended SSD)

Installation

First, is necessary have docker installed on your computer. I use Manajaro, so I just opened the terminal and type:

Installation Docker
pacman -S docker

Start docker services
systemctl start docker.service

Enable docker services to boot with system
systemctl enable docker.service

Testing docker:
docker run hello-world

Alright, now we'll download the docker osx and run using the command below:

docker run -it --device /dev/kvm -p 50922:10022 -e DEVICE_MODEL="iMacPro1,1" -e WIDTH=1440 -e HEIGHT=900 -e RAM=8 -e INTERNAL_SSH_PORT=23 -e AUDIO_DRIVER=alsa -e CORES=2 -v /tmp/.X11-unix:/tmp/.X11-unix -e "DISPLAY=${DISPLAY:-:0.0}" -e GENERATE_UNIQUE=true -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist sickcodes/docker-osx:big-sur
You can check what each flag means at github of docker osx.
but briefly, i specified the resolution, memory, cores of processor, version and others things.

Then, the docker osx will downloaded and initialized.

When the emulator opens, select option macOS Base System

When system be booted, select Disk Utility

Now, we'll search the partition that be with most storage space and select the option Erase.

To format, the chosen options must be strictly equal to this:

Click on Erase, wait process finish and then you can close the Disk Utility window.

Next, select the option Reinstall macOS Big Sur, accept the terms and select the partition we just created macOS and start installation. (This process can take 30 min ~ 1 hour).

So, the system must restart (or not), in my case, I had to do it manually because it didn't restart. In that case, close the QEMU window.

In terminal, we'll type:

docker ps -a

To know what is ID of our container and next we'll start typing the command below:

docker start ID

Select macOS Installer and the installation will continue.

Then, the system will restart automatically (or not), so close again the QUEMU and start again the container.

When the system boot, select option macOS Installer and wait the process finish. At end, the system will restart. (Now it's true).

Well, macOS was installed successfully. Select the option macOS.

Once that's done, it will restart again and you select the same macOS option.

Well done, welcome screen appeared. This configuration part is quite slow, but after this process finished, the system will work very well.

Configure the system , but don't login your AppleID at this moment.

When that process done, our desktop will appears and we'll wait until the dock appear because after this, the system will be most stable.

Now, we'll use the brew for install the packages more fast.

Open terminal in macOS and install brew with the command below:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Insert your password and wait the process finish.

Now, we'll install xcode on Apple Store.

So now, we can login on AppleID.

After that, wait for the installation.

Then, open xcode and accept the terms and wait install the dependencies.

So now, go at Preferences -> Locations -> Command-Line Tools it will be blank, select the option with the xCode version.

When the installation done, we'll open the terminal again and install cocoapods with command below. It serve as packager manager of xCode.

brew install cocoapods

Done that, our macOS will be installed and configured to run the projects.

Running a app with React Native

Okay, let's start with a hello world of React Native to check if everything we've done before will work.

I'll only check iOS.

Open the terminal and type:

Install node:
brew install node

Install yarn (optional):
npm install -g yarn

Creating a project with RN:
npx react-native init teste

If ask you to install cocoapods again, select the option with brew.

Enter at the project directory:
cd teste

Enter at ios directory:
cd ios

Install dependencies:
pod install

Back to root directory:
cd ..

List all simulate availaibles: (Optional)
xcrun simctl list devices

Run the project with xcode:
npx react-native run-ios --simulator="iPhone 13"

To a better experience, see section: Creating a connection of folders over SSH

Running a app with Cordova

Okay, let's start with a hello world of Quasar to check if everything we've done before will work.

I'll only check iOS.

Quasar uses Cordova/Capacitor for iOS and Android.

Install node:
brew install node

Install yarn (opcional):
npm install -g yarn

Install quasar:
yarn global add @quasar/cli

Install cordova:
yarn global add cordova

*Creating a project with Quasar:
quasar create teste

Enter in project directory:
cd teste

Add cordova in your project:
quasar mode add cordova

Enter in cordova directory:
cd src-cordova

Add iOS in project:
cordova platform add ios

Verify if everything is okay:
cordova requirements

List all simulate availables: (Opcional)
cordova emulate iOS --list

Install dependencies:
yarn

Back to root directory:
cd ..

Install dependencies:
yarn

Run quasar with development mode on iOS:
quasar dev -m iOS -e "iPhone 8, 15.2"

To a better experience, see section: Creating a connection of folders over SSH

Creating a connection of folders over SSH

Now our app is already running on macOS, we have a problem: Opening our code editor or IDE inside macOS is a very bad experience because of slowdowns, crashes, keyboard mapping and so on. So I researched a solution to create a file connection using SSH.

Also, I can open the development server inside macOS and create a connection where I can change files directly from my linux or macOS so that it updates on both sides, like a two-way. This guarantees us to take advantage of some things that exist in development mode, like fast refresh.

Connection from linux to mac

First, we need to allow connection via ssh via mac login. To do this, we will open the terminal and type:

Command to open edit ssh configuration file:
sudo nano /etc/ssh/sshd_config

Search for PasswordAuthentication and put yes and remove # at beginning line.

Save file.

Go to System Preferences -> Sharing -> Remote Login and active for all users:

Command to restart ssh:
sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd

Now, in linux terminal:

Install sshfs:
sudo pacman -S sshfs

Get container IP
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ID_CONTAINER

Create a folder:
mkdir projeto

Command to open a new connection with mac:
sudo sshfs USER_MAC@IP_CONTAINER:/PATH/OF/PROJECT/ON/MAC /PATH/ON/LINUX -p 23

Example:

Alright, now we can open the VSCode on linux and update the files updating directly on mac.

If you have another computer, you can do this connection and let your computer with emulator just emulating.

Connection from Mac to Linux

Same process previously, but the sshfs package on mac can be installed using the command below:

Install sshfs
brew install --cask macfuse && brew install gromgit/fuse/sshfs-mac

On Linux:

Command to edit ssh configuration file:
sudo nano /etc/ssh/sshd_config

Search for PasswordAuthentication and put yes and remove # at beginning line.

Save the file.

Command to restart SHH on Manjaro:
sudo systemctl restart sshd.service

On Mac, we'll create a folder to open connection.

Create a folder:
mkdir projeto

Command to open a new connection with linux
sudo sshfs USER_LINUX@IP_HOST:/PATH/LINUX /PATH/MAC -p 23

When we type the command, an error will occur.

Open the preferences and click Allow

Restart your mac.

Now, we can open the connection: (My SSH is opened in a different port, but the default is 22)

Once that's done, we can update from either side which will also reflect on both.

Final considerations

Thank you very much for reading this tutorial, by the way it's the first one I've published in years. Any questions or suggestions(mostly my english) are always welcome.

Oh, never update your mac.

Como emular um iOS no Linux utilizando Docker

Iaan Mesquita — Tue, 28 Dec 2021 21:47:12 +0000

AVISO

Estou disponível para oportunidades como Desenvolvedor Full-stack ou Desenvolvedor Back-end. Caso conheça algum posição em aberto, sinta-se à vontade para entrar em contato comigo no LinkedIn Iaan Mesquita :)

English version: How to emulate iOS on Linux with Docker

Depois de várias tentativas sem sucesso, enfim consegui virtualizar um macOS para fazer testes em um aplicativo iOS no qual eu estava trabalhando.

Mas antes de continuar, é necessário saber que essa não é uma solução estável e possue diversos problemas de desempenho, porém, para meu propósito consegui fazer o que queria.

Nós utilizaremos o QEMU para emular um macOS e dentro dele, utilizaremos o xCode para emular um iOS, só nisso você já consegue perceber que não vai ser uma coisa leve.

O repositório no github do Docker OSX tem uma explicação de como usar um iPhone via usb ao invés de emular, mas eu não tenho iPhone :p

Sumário

O que é o Docker OSX
Especificações de hardware
Instalação
Rodando um app com React Native
Rodando um app com Cordova
Criando uma conexão de pastas utilizando o sshfs
Considerações finais

O que é o Docker OSX

O Docker OSX é uma docker image que utiliza por debaixo dos panos o QEMU para que possamos emular um sistema operacional.

Leia mais: O que é docker?

Minhas especificações de hardware

As especificações do meu computador são consideradas OK pra fazer isso, porém, ainda consegui perceber algumas engasgadas enquanto utilizava o Docker OSX + xCode + Visual Studio Code + Dev Server. (Consegui até aquecer meu quarto com esse tanto de coisa.)

OS: Manjaro Linux x86_64
Kernel: 4.19.220-1-MANJARO
Shell: zsh 5.8
Resolution: 1440x900
DE: GNOME 41.2
WM: Mutter
WM Theme: Orchis-orange-compact
Icons: Win11-purple-dark [GTK2/3]
Terminal: gnome-terminal
CPU: Intel i7-3770 (8) @ 3.900GHz
GPU: NVIDIA GeForce GTX 1050 Ti
Memory: 4105MiB / 15985MiB
SSD: Crucial BX500 240gb (Altamente recomendado um SSD)

Instalação

Primeiramente, é necessário ter o docker instalado no seu computador. No meu caso eu utilizo Manjaro, então basta abrir o terminal e digitar:

Instalação docker
pacman -S docker

Ativando os serviços do docker
systemctl start docker.service

Ativando os serviços do docker para iniciar junto com o sistema
systemctl enable docker.service

Testando o docker:
docker run hello-world

Certo, agora iremos baixar a imagem e executa-la utilizando o comando abaixo:
docker run -it --device /dev/kvm -p 50922:10022 -e DEVICE_MODEL="iMacPro1,1" -e WIDTH=1440 -e HEIGHT=900 -e RAM=8 -e INTERNAL_SSH_PORT=23 -e AUDIO_DRIVER=alsa -e CORES=2 -v /tmp/.X11-unix:/tmp/.X11-unix -e "DISPLAY=${DISPLAY:-:0.0}" -e GENERATE_UNIQUE=true -e MASTER_PLIST_URL=https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom.plist sickcodes/docker-osx:big-sur

Você pode conferir o que cada flag significa olhando o repositório no github do docker osx, mas resumidamente, especifiquei a resolução, memória ram, cores do processador, versão big-sur do macOS e etc.

Em seguida, ele irá baixar a imagem e executar.

Quando abrir o emulador, de enter na opção macOS Base System

Quando carregar o sistema, clicaremos em Disk Utility

Agora, procuraremos a partição que está com mais espaço de armazenamento e clicaremos na opção Erase

Para formatar é preciso que as opções estejam estritamentes iguais a esta:

Clique em Erase, aguarde e pode fechar a janela do Disk Utility.

Em seguida, iremos em Reinstall macOS Big Sur aceitamos os termos, selecionamos a partição que acabamos de criar macOS e nisso, ele começará a instação do sistema. (Esse processo geralmente leva 30min ~ 1h).

Aguardado esse tempo, o sistema deve reiniciar (ou não), no meu caso, eu tive que fazer isso de forma manual pois ele não reiniciou. Nesse caso, feche a janela do QEMU.

Novamente no terminal, digitaremos:

docker ps -a

Para saber qual o ID do nosso container, e em seguida iremos inicia-lo com:

docker start ID

Selecione o macOS Installer e deixe que a instalação continue.

Após o processo, ele irá reiniciar automaticamente (ou não), sendo assim, feche novamente o emulador e dê start no container mais uma vez.

Ao iniciar, novamente selecione a opção macOS Installer e aguarde o processo terminar, feito isso ele irá reiniciar. (Agora é verdade).

Nosso macOS foi instalado, com isso, vamos selecionar a opção macOS.

Feito isso, irá reiniciar novamente e você selecione a mesma opção macOS.

Show, nossa tela de bem vindo apareceu. Essa parte é bastante lenta, mas após isso irá ficar normal.

Configure a sua maneira, mas não faça login no AppleID agora.

Após esse processo, nossa área de trabalho aparecerá e então iremos aguardar até a dock aparecer, pois após isso o sistema fica mais fluído.

Agora iremos utilizar o gerenciador brew para instalar as coisas mais rapidamente.

Abra o terminal no macOS e instale o brew com o comando:
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Irá pedir sua senha definida anteriormente para instalar.

Agora iremos instalar o xcode na apple store.

Agora sim, podemos fazer o login da nossa conta AppleID.

Feito isso, aguarde a instalação.
Em seguida, abra o xcode e aceite os termos e aguarde instalar as dependências.

Em seguida, vá em Preferences -> Locations -> Command-Line Tools vai estar vazio, selecione a opção com a versão do xcode.

Quando a instalação terminar, abriremos o terminal novamente e instalaremos o cocoapods. Ele serve como um gerenciador de dependências do xCode.

brew install cocoapods

Feito isso, nosso macOS está instalado e configurado para rodar os projetos.

Rodando um app com React Native

Vamos rodar um hello world do React Native para ver se está tudo certo, lembrando que não irei testar o android somente o iOS.

Abra o terminal

Instalação no node:
brew install node

Instalação do yarn (opcional):
npm install -g yarn

Criando um projeto react native:
npx react-native init teste

Se pedir pra instalar o cocoapods novamente, selecione a opção com brew.

Entrando no diretório do react native:
cd teste

Entrando no diretório do ios:
cd ios

Instalando as dependências:
pod install

Voltando para o diretório raiz:
cd ..

Listando os simuladores disponíveis: (Opcional)
xcrun simctl list devices

Rodando o projeto utilizando xcode:
npx react-native run-ios --simulator="iPhone 13"

Para uma experiência melhor, veja a seção: Criando uma conexão de pastas utilizando o sshfs

Rodando um app com Cordova

Vamos rodar um hello world do Quasar para ver se está tudo certo, lembrando que não irei testar o android somente o iOS.

Lembrando que o Quasar usa o Cordova/Capacitor pro iOS e Android.

Instalação no node:
brew install node

Instalação do yarn (opcional):
npm install -g yarn

Instalação do quasar:
yarn global add @quasar/cli

Instalação do cordova:
yarn global add cordova

Criando um projeto com Quasar-CLI:
quasar create teste

Entrando no diretório do projeto:
cd teste

Adicionando cordova ao projeto:
quasar mode add cordova

Entrar no diretório do cordova:
cd src-cordova

Adicionar o iOS ao projeto:
cordova platform add ios

Verificar se está tudo certo:
cordova requirements

Listar emuladores disponíveis: (Opcional)
cordova emulate iOS --list

Instalar as dependências do projeto:
yarn

Voltar ao diretório raiz:
cd ..

Instalar as dependências do projeto:
yarn

Rodar o quasar no modo desenvolvimento ioS:
quasar dev -m iOS -e "iPhone 8, 15.2"

Para uma experiência melhor, veja a seção: Criando uma conexão de pastas utilizando o sshfs

Criando uma conexão de pastas utilizando o sshfs

Agora que fizemos tudo e nosso app já está rodando no macOS, temos um problema: Abrir nosso editor de código ou IDE dentro do macOS é uma experiência muito ruim por causa da lentidão, glitches, mapping do teclado e etc. Dessa forma, eu pesquisei uma solução para criar uma conexão de arquivos utilizando o SSH.

Ou seja, eu posso abrir o servidor de desenvolvimento dentro do macOS e criar uma conexão em que eu possa alterar os arquivos direto do meu linux ou do macOS, de forma que atualize em ambos os lados, como uma via dupla. Isso nos garante tirar o proveito de algumas coisas que existem no modo desenvolvimento, como o fast refresh.

Conexão do Linux para o Mac

Primeiramente, precisamos permitir a conexão via ssh por login no mac. Para isso, abriremos o terminal e digitaremos:

Comando para abrir editar o arquivo de configuração do ssh:
sudo nano /etc/ssh/sshd_config

Busque por PasswordAuthentication e coloque a configuração como yes e remova o # no começo da linha.

Salve o arquivo.
Vá para em System Preferences -> Sharing -> Remote Login e ative para todos os usuários:

Comando para reiniciar o ssh:
sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd

Agora, no terminal do nosso Linux:

Instalação do sshfs:
sudo pacman -S sshfs

Pegando o IP do nosso container
docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ID_CONTAINER

Criar uma pasta:
mkdir projeto

Comando para abrir a conexão:
sudo sshfs USER_MAC@IP_CONTAINER:/CAMINHO/DO/PROJETO/NO/MAC /CAMINHO/NO/LINUX -p 23

Exemplo:

Pronto, agora eu posso abrir o visual studio code no meu Linux e atualizar diretamente no Mac.

Se você tiver um outro computador, pode fazer essa conexão também e deixar o seu principal apenas pra emular.

Conexão do Mac para o Linux

Mesmo processo anteriormente, só que o pacote do ssfs no mac pode ser instalado pelo comando abaixo.

Instalação sshfs no mac
brew install --cask macfuse && brew install gromgit/fuse/sshfs-mac

No Linux:

Comando para abrir editar o arquivo de configuração do ssh:
sudo nano /etc/ssh/sshd_config

Busque por PasswordAuthentication e coloque a configuração como yes e remova o # no começo da linha.

Salve o arquivo.

Comando para reiniciar o SSH no Manjaro:
sudo systemctl restart sshd.service

De volta ao mac, criaremos uma pasta e abriremos a conexão.

Criar uma pasta:
mkdir projeto

Comando para abrir a conexão:
sudo sshfs USER_LINUX@IP_HOST:/CAMINHO/LINUX /CAMINHO/MAC -p 23

Após rodar o comando, irá acontecer um erro:

Abra as prefêrencias e clique em Allow

Reincie o mac.

Agora podemos abrir nossa conexão: (Meu SSH está com uma porta diferente, mas a padrão é 22)

Feito isso, podemos atualizar de qualquer lado que também irá atualizar.

Considerações finais

Muito obrigado por ler este tutorial, que aliás, é o primeiro que publico depois de anos. Qualquer dúvida ou sugestão é sempre bem vinda.

Ah, nunca atualize o mac.