Vi skriver en säker webbläsartillägg

Till skillnad från den vanliga "klient-server"-arkitekturen kännetecknas decentraliserade applikationer av:

• Det finns inget behov av att lagra en databas med användarnamn och lösenord. Åtkomstinformationen lagras enbart av användarna själva, och valideringen av deras identitet sker på protokollnivå.
• Det finns inget behov av att använda en server. Applikationens logik kan köras i blockchain-nätverket, där det också är möjligt att lagra den nödvändiga datamängden.

Det finns 2 relativt säkra lagringsmetoder för användarnas nycklar — hårdvaruplånböcker och webbläsartillägg. Hårdvaruplånböcker är i de flesta fall maximalt säkra, men svåra att använda och långt ifrån gratis, medan webbläsartillägg erbjuder en perfekt kombination av säkerhet och användarvänlighet, och kan också vara helt gratis för slutanvändare.

Med detta i åtanke ville vi skapa ett så säkert tillägg som möjligt, som förenklar utvecklingen av decentraliserade applikationer genom att erbjuda ett enkelt API för transaktioner och signaturer.
Detta är vad vi kommer att berätta för er nedan.

I artikeln kommer det att finnas en steg-för-steg guide om hur man skriver ett webbläsartillägg, med kodexempel och skärmdumpar. All kod kan ni hitta i förrådet. Varje commit överensstämmer logiskt med avsnittet i denna artikel.

En kort historia om webbläsartillägg

Webbläsartillägg har funnits ganska länge. De dök upp i Internet Explorer redan 1999, och i Firefox — 2004. Trots detta dröjde det länge innan det fanns en enhetlig standard för tillägg.

Man kan säga att den uppkom samtidigt med tilläggen i den fjärde versionen av Google Chrome. Självklart fanns det ingen specifikation då, men just Chrome's API blev dess grund: med en stor del av webbläsarmarknaden och en inbyggd appbutik satte Chrome i praktiken standarden för webbläsartillägg.

Mozilla hade sin egen standard, men med tanke på populariteten för tillägg till Chrome beslutade företaget att skapa ett kompatibelt API. År 2015, på initiativ av Mozilla, skapades en särskild grupp inom World Wide Web Consortium (W3C) för att arbeta med specifikationerna för plattformsoberoende tillägg.

Grunden lades i en redan existerande API för Chrome-tillägg. Arbetet utfördes med stöd från Microsoft (Google vägrade delta i standardutvecklingen), och resultatet blev ett utkast. specifikationen.

Formellt stöds specifikationen av Edge, Firefox och Opera (notera att Chrome saknas i denna lista). Men i praktiken är standarden i stor utsträckning kompatibel även med Chrome, eftersom den faktiskt är skriven baserat på dess tillägg. Mer om WebExtensions API kan läsas. här.

Struktur för tillägget

Den enda fil som är absolut nödvändig för ett tillägg är manifestet (manifest.json). Det är också 'ingångspunkten' för tillägget.

Manifest

Enligt specifikationen är manifestfilen en giltig JSON-fil. En fullständig beskrivning av manifestnycklarna med information om vilka nycklar som stöds i vilken webbläsare kan ses. här.

Nycklar som inte finns i specifikationen 'kan' ignoreras (både Chrome och Firefox rapporterar fel, men tilläggen fortsätter att fungera).

Jag skulle vilja påpeka några punkter.

1. background — ett objekt som innehåller följande fält:
   1. scripts — en array av skripter som kommer att köras i background-context (vi pratar om detta lite senare);
   2. sidor — i stället för skripter som kommer att köras på en tom sida, kan man ange HTML med innehåll. I så fall kommer skriptfältet att ignoreras, och skripten måste sättas in i sidan med innehåll;
   3. beständiga — en binär flagga; om den inte anges, kommer webbläsaren att 'avsluta' bakgrundsprocessen när den anser att den inte gör något och starta om vid behov. Annars kommer sidan endast att laddas ur vid stängning av webbläsaren. Inte stöd i Firefox.
2. content_scripts — en array av objekt som möjliggör att ladda olika skript till olika webbsidor. Varje objekt innehåller följande viktiga fält:
   1. matches — URL-mönster, som används för att avgöra om ett specifikt content-script ska inkluderas eller inte.
   2. js — en lista över skript som kommer att laddas i det specifika matchningen;
   3. exclude_matches — utesluter fältet match URL:er som uppfyller detta fält.
3. page_action — är i själva verket ett objekt som ansvarar för ikonen som visas bredvid adressfältet i webbläsaren och interaktionen med den. Den möjliggör också att visa ett popup-fönster, vilket anges med hjälp av sin egen HTML, CSS och JS.
   1. default_popup — sökväg till HTML-filen med popup-gränssnittet, kan innehålla CSS och JS.
4. permissions — en array för att hantera rättigheter för tillägg. Det finns 3 typer av rättigheter, som beskrivs i detalj. ). Ett typiskt exempel på användning:
5. web_accessible_resources — resurser från tillägget som en webbsida kan begära, såsom bilder, JS-filer, CSS, HTML.
6. externally_connectable — här kan man uttryckligen ange ID:n för andra tillägg och domäner för webbsidor som kan ansluta. Domänen kan vara av andra nivåer och högre. Fungerar inte i Firefox.

Körkontext

Ett tillägg har tre körkontexter för kod, vilket innebär att applikationen består av tre delar med olika nivåer av åtkomst till webbläsarens API.

Tilläggskontext

Här är det mesta av API:t tillgängligt. I denna kontext «lever»:

1. Bakgrundssida — “backend”-delen av tillägget. Filen anges i manifestet under nyckeln “background”.
2. Popup-sida — popup-sidan som visas när man klickar på tilläggsikonen. I manifestet browser_action -> default_popup.
3. Anpassad sida — tilläggssidan som «lever» på en separat flik av typen chrome-extension:///customPage.html.

Denna kontext existerar oberoende av webbläsarens fönster och flikar. Bakgrundssida finns i ett enda exemplar och är alltid aktiv (undantag är event page, där bakgrundsskriptet startas vid en händelse och «dör» efter att den har körts). Popup-sida existerar när popup-fönstret är öppet, och Anpassad sida — så länge en flik med den är öppen. Ingen åtkomst till andra flikar eller deras innehåll finns från denna kontext.

Innehållsskriptkontext

Innehållsskriptfilen körs samtidigt med varje webbläsartab. Den har tillgång till delar av tilläggs-API:t och DOM-trädet på webbsidan. Det är innehållsskripten som ansvarar för interaktionen med sidan. Tillägg som manipulerar DOM-trädet gör detta i innehållsskripten – till exempel annonsblockerare eller översättare. Innehållsskript kan också kommunicera med sidan via standardmetoden postMessage.

Webbsidors kontext

Det är själva webbsidan. Den har ingen relation till tillägget och har ingen åtkomst dit, förutom när domänen för denna sida uttryckligen anges i manifestet (mer om detta nedan).

Meddelandebyte

Olika delar av applikationen måste utbyta meddelanden med varandra. För detta finns API:t runtime.sendMessage för att skicka meddelanden background och tabs.sendMessage för att skicka meddelanden till sidan (innehållsskriptet, popup:en eller webbsidan om externally_connectable). Här är ett exempel på hur man anropar Chrome API.

// Сообщением может быть любой JSON сериализуемый объект
const msg = {a: 'foo', b: 'bar'};

// extensionId можно не указывать, если мы хотим послать сообщение 'своему' расширению (из ui или контент скрипта)
chrome.runtime.sendMessage(extensionId, msg);

// Так выглядит обработчик
chrome.runtime.onMessage.addListener((msg) => console.log(msg))

// Можно слать сообщения вкладкам зная их id
chrome.tabs.sendMessage(tabId, msg)

// Получить к вкладкам и их id можно, например, вот так
chrome.tabs.query(
    {currentWindow: true, active : true},
    function(tabArray){
      tabArray.forEach(tab => console.log(tab.id))
    }
)

För att möjliggöra fullständig kommunikation kan man skapa anslutningar via runtime.connect. Som svar får vi runtime.Port, i vilken vi kan skicka ett obegränsat antal meddelanden så länge den är öppen. På klientsidan, till exempel, contentscript, ser det ut så här:

// Опять же extensionId можно не указывать при коммуникации внутри одного расширения. Подключение можно именовать
const port = chrome.runtime.connect({name: "knockknock"});
port.postMessage({joke: "Knock knock"});
port.onMessage.addListener(function(msg) {
    if (msg.question === "Who's there?")
        port.postMessage({answer: "Madame"});
    else if (msg.question === "Madame who?")
        port.postMessage({answer: "Madame... Bovary"});

Server eller background:

// Обработчик для подключения 'своих' вкладок. Контент скриптов, popup или страниц расширения
chrome.runtime.onConnect.addListener(function(port) {
    console.assert(port.name === "knockknock");
    port.onMessage.addListener(function(msg) {
        if (msg.joke === "Knock knock")
            port.postMessage({question: "Who's there?"});
        else if (msg.answer === "Madame")
            port.postMessage({question: "Madame who?"});
        else if (msg.answer === "Madame... Bovary")
            port.postMessage({question: "I don't get it."});
    });
});

// Обработчик для подключения внешних вкладок. Других расширений или веб страниц, которым разрешен доступ в манифесте
chrome.runtime.onConnectExternal.addListener(function(port) {
    ...
});

Det finns också en händelse onDisconnect och metoden koppla ifrån.

App-schema

Låt oss skapa en webbläsartillägg som lagrar privata nycklar, ger tillgång till offentlig information (adress, offentlig nyckel kommunicerar med sidan) och tillåter tredjepartsapplikationer att begära signaturer av transaktioner.

Utveckling av applikation

Vår applikation bör både interagera med användaren och tillhandahålla en API för sidan för att anropa metoder (till exempel för att signera transaktioner). Att endast använda contentscript går inte, eftersom den bara har tillgång till DOM, men inte till JS på sidan. Att koppla upp sig via runtime.connect kan vi inte göra, eftersom API:t behövs på alla domäner, men i manifestet kan man bara ange specifika. Slutresultatet kommer att se ut så här:

Det kommer att finnas ett annat skript — inpage, som vi kommer att injicera på sidan. Det kommer att exekveras i dess kontext och tillhandahålla API för samarbete med tillägget.

Början

All kod för webbläsartillägget finns tillgänglig på GitHub. I beskrivningen kommer det att finnas länkar till commits.

Vi börjar med manifestet:

{
  // Namn och beskrivning, version. Allt detta kommer att synas i webbläsaren på chrome://extensions/?id=<extension-id>
  "name": "Signer",
  "description": "Extension demo",
  "version": "0.0.1",
  "manifest_version": 2,

  // Skripten som kommer att köras i bakgrunden, det kan finnas flera
  "background": {
    "scripts": ["background.js"]
  },

  // Vilken HTML som ska användas för popup
  "browser_action": {
    "default_title": "My Extension",
    "default_popup": "popup.html"
  },

  // Innehållsskript.
  // Vi har ett objekt: för alla url:er som börjar med http eller https kör vi
  // innehållsskript-kontext med skriptet contentscript.js. Starta omedelbart vid dokumentets mottagande för alla ramar
  "content_scripts": [
    {
      "matches": [
        "http:/*/*",
        "https:/*/*"
      ],
      "js": [
        "contentscript.js"
      ],
      "run_at": "document_start",
      "all_frames": true
    }
  ],
  // Åtkomst till localStorage och idle API tillåts
  "permissions": [
    "storage",
    // "unlimitedStorage",
    //"clipboardWrite",
    "idle"
    //"activeTab",
    //"webRequest",
    //"notifications",
    //"tabs"
  ],
  // Här anges resurser till vilka webbplatsen kommer att ha tillgång. Det betyder att de kan begäras med fetch eller bara xhr
  "web_accessible_resources": ["inpage.js"]
}

Vi skapar tomma background.js, popup.js, inpage.js och contentscript.js. Vi lägger till popup.html – och vår applikation kan redan laddas upp i Google Chrome för att se om den fungerar.

För att bekräfta detta kan vi ta koden härifrån. Utöver det vi har gjort, så är det en länk för att sätta upp projektet med webpack. För att lägga till applikationen i webbläsaren, gå till chrome://extensions, välj load unpacked och mappen med motsvarande tillägg – i vårt fall dist.

Nu är vårt tillägg installerat och fungerar. Utvecklarverktyg för olika kontexter kan startas på följande sätt:

popup ->

Tillgång till innehållsskriptets konsol görs via konsolen på den sida där det körs.

Meddelandebyte

Så vi behöver sätta upp två kommunikationskanaler: inpage background och popup background. Visst kan vi bara skicka meddelanden till porten och uppfinna vårt eget protokoll, men jag föredrar den metod jag sett i det öppna projektet metamask.

Detta är en webbläsartillägg för att arbeta med Ethereum-nätverket. I det kommunicerar olika delar av applikationen via RPC med hjälp av biblioteket dnode. Det möjliggör snabb och bekväm kommunikation om vi tillhandahåller nodejs-stream som transport (med det menar jag ett objekt som implementerar samma gränssnitt):

import Dnode from "dnode/browser";

// I det här exemplet förutsätter vi att klienten fjärran anropar funktioner på servern, även om inget hindrar oss från att göra det tvåvägs

// Server
// API som vi vill tillhandahålla
const dnode = Dnode({
    hello: (cb) => cb(null, "world")
})
// Transport som dnode kommer att fungera ovanpå. Valfri nodejs-stream. I webbläsaren finns biblioteket 'readable-stream'
connectionStream.pipe(dnode).pipe(connectionStream)

// Klient
const dnodeClient = Dnode() // Anrop utan argument betyder att vi inte tillhandahåller API på andra sidan

// Skriver ut 'world' i konsolen
dnodeClient.once('remote', remote => {
    remote.hello((err, value) => console.log(value))
})

Nu kommer vi att skapa en klass för applikationen. Den kommer att skapa API-objekt för popup och webbsidan samt skapa dnode för dem:

import Dnode from 'dnode/browser';

export class SignerApp {

    // Return API object for UI
    popupApi(){
        return {
            hello: cb => cb(null, 'world')
        }
    }

    // Return API object for page
    pageApi(){
        return {
            hello: cb => cb(null, 'world')
        }
    }

    // Connects popup UI
    connectPopup(connectionStream){
        const api = this.popupApi();
        const dnode = Dnode(api);

        connectionStream.pipe(dnode).pipe(connectionStream);

        dnode.on('remote', (remote) => {
            console.log(remote)
        })
    }

    // Connects page
    connectPage(connectionStream, origin){
        const api = this.popupApi();
        const dnode = Dnode(api);

        connectionStream.pipe(dnode).pipe(connectionStream);

        dnode.on('remote', (remote) => {
            console.log(origin);
            console.log(remote)
        })
    }
}

Här och framåt använder vi istället det globala objektet Chrome som extentionApi, vilket adresserar Chrome i Googles webbläsare och browser i andra. Detta görs för att säkerställa cross-browser stöd, men inom ramen för denna artikel skulle man också kunna använda ‘chrome.runtime.connect’.

Skapa en instans av applikationen i bakgrundsskriptet:

import {extensionApi} from './utils/extensionApi';
import {PortStream} from './utils/PortStream';
import {SignerApp} from './SignerApp';

const app = new SignerApp();

// onConnect utlöses vid anslutning av 'processer' (contentscript, popup eller sida av tillägget)
extensionApi.runtime.onConnect.addListener(connectRemote);

function connectRemote(remotePort) {
    const processName = remotePort.name;
    const portStream = new PortStream(remotePort);
    // Vid anslutning kan man ange namn, och det namnet använder vi för att identifiera vem som anslutit sig, contentscript eller UI
    if (processName === 'contentscript'){
        const origin = remotePort.sender.url
        app.connectPage(portStream, origin)
    }else{
        app.connectPopup(portStream)
    }
}

Eftersom dnode arbetar med strömmar och vi tar emot en port, behövs en adapterklass. Den är skapad med hjälp av biblioteket readable-stream, som implementerar nodejs-strömmar i webbläsaren:

import {Duplex} from 'readable-stream';

export class PortStream extends Duplex{
    constructor(port){
        super({objectMode: true});
        this._port = port;
        port.onMessage.addListener(this._onMessage.bind(this));
        port.onDisconnect.addListener(this._onDisconnect.bind(this))
    }

    _onMessage(msg) {
        if (Buffer.isBuffer(msg)) {
            delete msg._isBuffer;
            const data = new Buffer(msg);
            this.push(data)
        } else {
            this.push(msg)
        }
    }

    _onDisconnect() {
        this.destroy()
    }

    _read(){}

    _write(msg, encoding, cb) {
        try {
            if (Buffer.isBuffer(msg)) {
                const data = msg.toJSON();
                data._isBuffer = true;
                this._port.postMessage(data)
            } else {
                this._port.postMessage(msg)
            }
        } catch (err) {
            return cb(new Error('PortStream - disconnected'))
        }
        cb()
    }
}

Nu skapar vi en anslutning i UI:

import {extensionApi} from "./utils/extensionApi";
import {PortStream} from "./utils/PortStream";
import Dnode from 'dnode/browser';

const DEV_MODE = process.env.NODE_ENV !== 'production';

setupUi().catch(console.error);

async function setupUi(){
    // Precis som i applikationsklassen skapar vi en port, lindar in den i en stream och gör en dnode
    const backgroundPort = extensionApi.runtime.connect({name: 'popup'});
    const connectionStream = new PortStream(backgroundPort);

    const dnode = Dnode();

    connectionStream.pipe(dnode).pipe(connectionStream);

    const background = await new Promise(resolve => {
        dnode.once('remote', api => {
            resolve(api)
        })
    });

    // Gör API-objektet tillgängligt från konsolen
    if (DEV_MODE){
        global.background = background;
    }
}

Därefter skapar vi en anslutning i innehållsskriptet:

import {extensionApi} from "./utils/extensionApi";
import {PortStream} from "./utils/PortStream";
import PostMessageStream from 'post-message-stream';

setupConnection();
injectScript();

function setupConnection(){
    const backgroundPort = extensionApi.runtime.connect({name: 'contentscript'});
    const backgroundStream = new PortStream(backgroundPort);

    const pageStream = new PostMessageStream({
        name: 'content',
        target: 'page',
    });

    pageStream.pipe(backgroundStream).pipe(pageStream);
}

function injectScript(){
    try {
        // injicera skript på sidan
        let script = document.createElement('script');
        script.src = extensionApi.extension.getURL('inpage.js');
        const container = document.head || document.documentElement;
        container.insertBefore(script, container.children[0]);
        script.onload = () => script.remove();
    } catch (e) {
        console.error('Injektion misslyckades.', e);
    }
}

Eftersom API:et inte behövs i innehållsskriptet utan direkt på sidan, gör vi två saker:

1. Skapar två streamar. En mot sidan, ovanför postMessage. För detta använder vi detta paket från skaparna av metamask. Den andra streamen — till bakgrunden ovanför porten som erhållits från runtime.connect. Vi pipar dem. Nu kommer sidan ha en stream till bakgrunden.
2. Injicerar skriptet i DOM. Vi hämtar skriptet (åtkomst till det har beviljats i manifestet) och skapar en tagg script med dess innehåll inuti:

import PostMessageStream from 'post-message-stream';
import {extensionApi} from "./utils/extensionApi";
import {PortStream} from "./utils/PortStream";

setupConnection();
injectScript();

function setupConnection(){
    // Stream till bakgrunden
    const backgroundPort = extensionApi.runtime.connect({name: 'contentscript'});
    const backgroundStream = new PortStream(backgroundPort);

    // Stream till sidan
    const pageStream = new PostMessageStream({
        name: 'content',
        target: 'page',
    });

    pageStream.pipe(backgroundStream).pipe(pageStream);
}

function injectScript(){
    try {
        // injicera skript på sidan
        let script = document.createElement('script');
        script.src = extensionApi.extension.getURL('inpage.js');
        const container = document.head || document.documentElement;
        container.insertBefore(script, container.children[0]);
        script.onload = () => script.remove();
    } catch (e) {
        console.error('Injektion misslyckades.', e);
    }
}

Nu skapar vi ett API-objekt i inpage och gör det globalt:

import PostMessageStream from 'post-message-stream';
import Dnode from 'dnode/browser';

setupInpageApi().catch(console.error);

async function setupInpageApi() {
    // Stream to the content script
    const connectionStream = new PostMessageStream({
        name: 'page',
        target: 'content',
    });

    const dnode = Dnode();

    connectionStream.pipe(dnode).pipe(connectionStream);

    // Getting the API object
    const pageApi = await new Promise(resolve => {
        dnode.once('remote', api => {
            resolve(api)
        })
    });

    // Access through window
    global.SignerApp = pageApi;
}

Vi är klara Remote Procedure Call (RPC) med separat API för sidan och UI. När en ny sida kopplas till bakgrunden kan vi se detta:

Tom API och origin. På sidan kan vi anropa funktionen hello så här:

Att arbeta med callback-funktioner i modern JS är förlegat, så vi skriver en liten hjälpare för att skapa dnode, som möjliggör att överföra till API-objektet i utils.

API-objekten kommer nu att se ut så här:

export class SignerApp {

    popupApi() {
        return {
            hello: async () => "world"
        }
    }

...

}

Få objektet från remote på följande sätt:

import {cbToPromise, transformMethods} from "../src/utils/setupDnode";

const pageApi = await new Promise(resolve => {
    dnode.once('remote', remoteApi => {
        // Med hjälp av verktyg förändrar vi alla callbacks till promises
        resolve(transformMethods(cbToPromise, remoteApi))
    })
});

Och anrop av funktioner returnerar ett promise:

Versionen med asynkrona funktioner är tillgänglig här.

Överlag verkar tillvägagångssättet med RPC och strömmar tillräckligt flexibelt: vi kan använda stream multiplexing och skapa flera olika API:er för olika uppgifter. I princip kan dnode användas överallt, det viktigaste är att slå in transporten som en nodejs-stream.

Ett alternativ är JSON-formatet, som implementerar protokollet JSON RPC 2. Men det fungerar med specifika transportprotokoll (TCP och HTTP(S)), vilket i vårt fall inte är tillämpligt.

Intern status och localStorage

Vi kommer att behöva lagra den interna statusen för applikationen — minst nycklarna för signering. Vi kan ganska enkelt lägga till status i applikationen och metoder för att ändra den i popup API:

import {setupDnode} from "./utils/setupDnode";

export class SignerApp {

    constructor(){
        this.store = {
            keys: [],
        };
    }

    addKey(key){
        this.store.keys.push(key)
    }

    removeKey(index){
        this.store.keys.splice(index,1)
    }

    popupApi(){
        return {
            addKey: async (key) => this.addKey(key),
            removeKey: async (index) => this.removeKey(index)
        }
    }

    ...

} 

I bakgrunden sveper vi allt i en funktion och skriver objektet för applikationen i window, så att vi kan arbeta med det från konsolen:

import {extensionApi} from "./utils/extensionApi";
import {PortStream} from "./utils/PortStream";
import {SignerApp} from "./SignerApp";

const DEV_MODE = process.env.NODE_ENV !== 'production';

setupApp();

function setupApp() {
    const app = new SignerApp();

    if (DEV_MODE) {
        global.app = app;
    }

    extensionApi.runtime.onConnect.addListener(connectRemote);

    function connectRemote(remotePort) {
        const processName = remotePort.name;
        const portStream = new PortStream(remotePort);
        if (processName === 'contentscript') {
            const origin = remotePort.sender.url;
            app.connectPage(portStream, origin)
        } else {
            app.connectPopup(portStream)
        }
    }
}

Låt oss lägga till några nycklar från UI-konsolen och se vad som har hänt med tillståndet:

Tillståndet måste göras beständigt så att nycklarna inte går förlorade vid omstart.

Vi ska lagra det i localStorage och skriva över det vid varje förändring. Senare kommer tillgång till det också att vara nödvändig för UI, och vi vill även kunna prenumerera på förändringar. Utifrån detta blir det praktiskt att skapa ett observerbart lager (observable storage) och prenumerera på dess förändringar.

Vi kommer att använda mobx-biblioteket (https://github.com/mobxjs/mobx). Valet föll på det eftersom jag aldrig har arbetat med det och verkligen ville lära mig det.

Låt oss lägga till initialisering av det initiala tillståndet och göra lagret observerbart:

import {observable, action} from 'mobx';
import {setupDnode} from "./utils/setupDnode";

export class SignerApp {

    constructor(initState = {}) {
        // Externt kommer lagret fortsatt att vara samma objekt, men nu har alla dess fält blivit proxy som övervakar åtkomst till dem
        this.store = observable.object({
            keys: initState.keys || [],
        });
    }

    // Metoder som ändrar observable brukar omges av dekorator
    @action
    addKey(key) {
        this.store.keys.push(key)
    }

    @action
    removeKey(index) {
        this.store.keys.splice(index, 1)
    }

    ...

}

«Under huven» har mobx ersatt alla fält i lagret med proxy och fångar alla åtkomster till dem. Det är möjligt att prenumerera på dessa åtkomster.

Jag kommer senare att ofta använda termen “vid förändring”, även om det inte är helt korrekt. Mobx övervakar just åtkomst till fälten. Getter- och setter-metoder för proxy-objekten används, som biblioteken skapar.

Dekoratorer för action tjänar två syften:

1. I strikt läge med flaggan enforceActions förbjuder mobx att direkt ändra tillståndet. Det anses vara god praxis att arbeta just i strikt läge.
2. Även om funktionen ändrar tillstånd flera gånger – till exempel, om vi ändrar flera fält på flera rader kod – så meddelas observatörerna endast när den är klar. Detta är särskilt viktigt för frontenden, där onödiga uppdateringar av tillståndet leder till oönskad rendering av element. I vårt fall är varken det första eller det andra särskilt relevant, men vi kommer att följa bästa praxis. Dekoratorer brukar tillämpas på alla funktioner som ändrar tillståndet för observerade fält.

I bakgrunden lägger vi till initialisering och sparande av tillståndet i localStorage:

import {reaction, toJS} from 'mobx';
import {extensionApi} from ".\/utils\/extensionApi";
import {PortStream} from ".\/utils\/PortStream";
import {SignerApp} from ".\/SignerApp";
// Hjälpmetoder. Skrivs/läses objekt i/från localStorage i form av en JSON-sträng med nyckeln 'store'
import {loadState, saveState} from ".\/utils\/localStorage";

const DEV_MODE = process.env.NODE_ENV !== 'production';

setupApp();

function setupApp() {
    const initState = loadState();
    const app = new SignerApp(initState);

    if (DEV_MODE) {
        global.app = app;
    }

    // Inställning av tillståndsparallelisering

    // Resultatet av reaction tilldelas en variabel så att prenumerationen kan avbrytas. Vi behöver inte detta, kvarlämnat som exempel
    const localStorageReaction = reaction(
        () => toJS(app.store), // Funktion för dataval
        saveState // Funktion som kommer att anropas vid ändring av data som returneras av valfunktion
    );

    extensionApi.runtime.onConnect.addListener(connectRemote);

    function connectRemote(remotePort) {
        const processName = remotePort.name;
        const portStream = new PortStream(remotePort);
        if (processName === 'contentscript') {
            const origin = remotePort.sender.url
            app.connectPage(portStream, origin)
        } else {
            app.connectPopup(portStream)
        }
    }
}

Den intressanta funktionen här är reaction. Den har två parametrar:

1. Dataval
2. En callback som kommer att anropas med dessa data varje gång de ändras.

Till skillnad från redux, där vi tydligt får tillståndet som en parameter, kommer mobx ihåg vilka observerbara vi refererar till inom valfunktionen, och anropar endast callbacken när de ändras.

Det är viktigt att förstå hur mobx bestämmer vilka observerbara vi prenumererar på. Om jag i koden skrev valfunktionen på det sättet() => app.store, så skulle reaction aldrig anropas, eftersom själva lagret inte är observerbart; endast dess fält är det.

Om jag skrev den så här () => app.store.keys, så skulle igen ingenting hända, eftersom länken till den inte skulle förändras vid tillägg/borttagning av element i arrayen.

Mobx utför för första gången en selektorfunktion och övervakar endast de observable som vi hade tillgång till. Detta görs genom proxygetters. Därför används en inbyggd funktion här. toJS. Den returnerar ett nytt objekt där alla proxies har ersatts av de ursprungliga fälten. Under körning läser den alla fält i objektet – därmed aktiveras getternas funktioner.

I popupkonsolen lägger vi till några nycklar igen. Den här gången hamnar de också i localStorage:

Vid omladdning av bakgrundssidan förblir informationen på plats.

Hele applikationens kod fram till detta ögonblick kan ses. här.

Säker förvaring av privata nycklar

Att lagra privata nycklar i klartext är osäkert: det finns alltid en risk att du blir hackad och får tillgång till din dator med mera. Därför kommer vi att lagra nycklarna i lokal lagring i ett lösenordskrypterat format.

För ökad säkerhet kommer vi att lägga till ett låst tillstånd i applikationen, där det inte kommer att finnas något tillgång till nycklarna överhuvudtaget. Vi kommer automatiskt att överföra tillägget till det låsta tillståndet efter en timeout.

Mobx gör det möjligt att lagra endast en minimal mängd data, och automatiskt beräkna resten baserat på dessa. Detta kallas för computed properties. De kan jämföras med views i databaser:

import {observable, action} from 'mobx';
import {setupDnode} from ".\/utils\/setupDnode";
// Verktyg för säker kryptering av strängar. Använder crypto-js
import {encrypt, decrypt} from ".\/utils\/cryptoUtils";

export class SignerApp {
    constructor(initState = {}) {
        this.store = observable.object({
            // Lagrar lösenord och krypterade nycklar. Om lösenord är null - appen är låst
            password: null,
            vault: initState.vault,

            // Getters för beräknade fält. Kan liknas vid vy i databasen.
            get locked(){
                return this.password == null
            },
            get keys(){
                return this.locked ?
                    undefined :
                    SignerApp._decryptVault(this.vault, this.password)
            },
            get initialized(){
                return this.vault !== undefined
            }
        })
    }
    // Initiera ett tomt förråd med ett nytt lösenord
    @action
    initVault(password){
        this.store.vault = SignerApp._encryptVault([], password)
    }
    @action
    lock() {
        this.store.password = null
    }
    @action
    unlock(password) {
        this._checkPassword(password);
        this.store.password = password
    }
    @action
    addKey(key) {
        this._checkLocked();
        this.store.vault = SignerApp._encryptVault(this.store.keys.concat(key), this.store.password)
    }
    @action
    removeKey(index) {
        this._checkLocked();
        this.store.vault = SignerApp._encryptVault([
                ...this.store.keys.slice(0, index),
                ...this.store.keys.slice(index + 1)
            ],
            this.store.password
        )
    }

    ... // kod för anslutning och api

    // privat
    _checkPassword(password) {
        SignerApp._decryptVault(this.store.vault, password);
    }

    _checkLocked() {
        if (this.store.locked){
            throw new Error('Appen är låst')
        }
    }

    // Metoder för kryptering/dekryptering av förrådet
    static _encryptVault(obj, pass){
        const jsonString = JSON.stringify(obj)
        return encrypt(jsonString, pass)
    }

    static _decryptVault(str, pass){
        if (str === undefined){
            throw new Error('Förrådet är inte initierat')
        }
        try {
            const jsonString = decrypt(str, pass)
            return JSON.parse(jsonString)
        }catch (e) {
            throw new Error('Fel lösenord')
        }
    }
}

Nu lagrar vi endast krypterade nycklar och lösenord. Allt annat beräknas. Övergången till låst tillstånd görs genom att ta bort lösenordet från tillståndet. I det publika API:t har en metod för att initiera förrådet tillkommit.

För kryptering har verktyg skrivits med hjälp av crypto-js:

import CryptoJS from 'crypto-js'

// Används för att komplicera gissning av lösenord genom brute-force. För varje lösenord alternativ måste angriparen göra 5000 hashningar
function strengthenPassword(pass, rounds = 5000) {
    while (rounds-- > 0){
        pass = CryptoJS.SHA256(pass).toString()
    }
    return pass
}

export function encrypt(str, pass){
    const strongPass = strengthenPassword(pass);
    return CryptoJS.AES.encrypt(str, strongPass).toString()
}

export function decrypt(str, pass){
    const strongPass = strengthenPassword(pass)
    const decrypted = CryptoJS.AES.decrypt(str, strongPass);
    return decrypted.toString(CryptoJS.enc.Utf8)
}

Webbläsaren har ett Idle API som gör att man kan prenumerera på händelsen – statusemändringar. Status kan därmed vara inaktiv, active och låst. För idle kan man ställa in en tidsgräns, och låst sätts när operativsystemet själv blockeras. Vi kommer också att ändra selektorn för att spara i localStorage:

import {reaction, toJS} from 'mobx';
import {extensionApi} from ".\/utils\/extensionApi";
import {PortStream} from ".\/utils\/PortStream";
import {SignerApp} from ".\/SignerApp";
import {loadState, saveState} from ".\/utils\/localStorage";

const DEV_MODE = process.env.NODE_ENV !== 'production';
const IDLE_INTERVAL = 30;

setupApp();

function setupApp() {
    const initState = loadState();
    const app = new SignerApp(initState);

    if (DEV_MODE) {
        global.app = app;
    }

    \/\/ Här anropar vi tydligt fältet, som kommer att användas, reaktionen fungerar korrekt
    reaction(
        () => ({
            vault: app.store.vault
        }),
        saveState
    );

    \/\/ Tidsgräns för inaktivitet när händelsen inträffar
    extensionApi.idle.setDetectionInterval(IDLE_INTERVAL);
    \/\/ Om användaren låser skärmen eller är inaktiv under den angivna tidsgränsen, låser vi applikationen
    extensionApi.idle.onStateChanged.addListener(state => {
        if (['locked', 'idle'].indexOf(state) > -1) {
            app.lock()
        }
    });

    \/\/ Anslut till andra sammanhang
    extensionApi.runtime.onConnect.addListener(connectRemote);

    function connectRemote(remotePort) {
        const processName = remotePort.name;
        const portStream = new PortStream(remotePort);
        if (processName === 'contentscript') {
            const origin = remotePort.sender.url
            app.connectPage(portStream, origin)
        } else {
            app.connectPopup(portStream)
        }
    }
}

Koden fram till detta steg finns här.

Transaktioner

Så, vi har kommit till det viktigaste: skapandet och signeringen av transaktioner i blockkedjan. Vi kommer att använda WAVES blockkedjan och biblioteket waves-transactions.

För att börja lägger vi till en array av meddelanden i statusen som behöver signeras, sedan – metoder för att lägga till ett nytt meddelande, bekräfta signaturen och avböja:

import {action, observable, reaction} from 'mobx';
import uuid from 'uuid/v4';
import {signTx} from '@waves/waves-transactions'
import {setupDnode} from "./utils/setupDnode";
import {decrypt, encrypt} from "./utils/cryptoUtils";

export class SignerApp {

    ...

    @action
    newMessage(data, origin) {
        // För varje meddelande skapar vi metadata med id, status, skapad tid osv.
        const message = observable.object({
            id: uuid(), // Identifierare, använder uuid
            origin, // Origin kommer vi senare visa i gränssnittet
            data, //
            status: 'new', // Det kommer finnas fyra statusar: new, signed, rejected och failed
            timestamp: Date.now()
        });
        console.log(`nytt meddelande: ${JSON.stringify(message, null, 2)}`);

        this.store.messages.push(message);

        // Vi returnerar ett löfte där mobx övervakar ändringar i meddelandet. Så snart status ändras kommer vi att lösa det
        return new Promise((resolve, reject) => {
            reaction(
                () => message.status, // Vi kommer att observera statusen av meddelandet
                (status, reaction) => { // den andra argumentet är en referens till själva reaction, så att den kan tas bort inuti anropet
                    switch (status) {
                        case 'signed':
                            resolve(message.data);
                            break;
                        case 'rejected':
                            reject(new Error('Användaren avslog meddelandet'));
                            break;
                        case 'failed':
                            reject(new Error(message.err.message));
                            break;
                        default:
                            return
                    }
                    reaction.dispose()
                }
            )
        })
    }
    @action
    approve(id, keyIndex = 0) {
        const message = this.store.messages.find(msg => msg.id === id);
        if (message == null) throw new Error(`Inga meddelanden med id:${id}`);
        try {
            message.data = signTx(message.data, this.store.keys[keyIndex]);
            message.status = 'signed'
        } catch (e) {
            message.err = {
                stack: e.stack,
                message: e.message
            };
            message.status = 'failed'
            throw e
        }
    }
    @action
    reject(id) {
        const message = this.store.messages.find(msg => msg.id === id);
        if (message == null) throw new Error(`Inga meddelanden med id:${id}`);
        message.status = 'rejected'
    }

    ...
}

När vi får ett nytt meddelande lägger vi till metadata i det, vi gör observable och lägger till i store.messages.

Om vi inte gör det observable manuellt kommer mobx att göra det automatisk när det läggs till i arrayen messages. Men den kommer att skapa ett nytt objekt, som vi inte kommer att ha en referens till, vilket behövs för nästa steg.

Vi returnerar sedan ett löfte som löses när meddelandets status ändras. Statusen övervakas av en reaction, som självmant "dödas" vid statusändring.

Kod för metoderna approve och reject är mycket enkel: vi ändrar bara meddelandets status, efter att ha signerat det om det behövs.

Vi hanterar godkännande och avvisande i API UI, newMessage — på API-sidan:

export class SignerApp {
    ...
    popupApi() {
        return {
            addKey: async (key) => this.addKey(key),
            removeKey: async (index) => this.removeKey(index),

            lock: async () => this.lock(),
            unlock: async (password) => this.unlock(password),
            initVault: async (password) => this.initVault(password),

            approve: async (id, keyIndex) => this.approve(id, keyIndex),
            reject: async (id) => this.reject(id)
        }
    }

    pageApi(origin) {
        return {
            signTransaction: async (txParams) => this.newMessage(txParams, origin)
        }
    }

    ...
}

Låt oss nu försöka signera en transaktion med tillägget:

I stort sett är allt klart, vi behöver bara lägga till ett enkelt UI.

UI

UI:t behöver åtkomst till applikationens tillstånd. På UI-sidan kommer vi att göra observable ett tillstånd och lägga till en funktion i API:t som kommer att ändra detta tillstånd. Vi lägger till observable i API-objektet som fås från bakgrunden:

import {observable} from 'mobx'
import {extensionApi} from "./utils/extensionApi";
import {PortStream} from "./utils/PortStream";
import {cbToPromise, setupDnode, transformMethods} from "./utils/setupDnode";
import {initApp} from "./ui/index";

const DEV_MODE = process.env.NODE_ENV !== 'production';

setupUi().catch(console.error);

async function setupUi() {
    // Ansluter till porten, skapar en ström från den
    const backgroundPort = extensionApi.runtime.connect({name: 'popup'});
    const connectionStream = new PortStream(backgroundPort);

    // Skapar en tom observable för bakgrundens tillstånd
    let backgroundState = observable.object({});
    const api = {
        // Ger bakgrunden en funktion som kommer att uppdatera observable
        updateState: async state => {
            Object.assign(backgroundState, state)
        }
    };

    // Skapar RPC-objekt
    const dnode = setupDnode(connectionStream, api);
    const background = await new Promise(resolve => {
        dnode.once('remote', remoteApi => {
            resolve(transformMethods(cbToPromise, remoteApi))
        })
    });

    // Lägger till observable med tillståndet i bakgrunden
    background.state = backgroundState;

    if (DEV_MODE) {
        global.background = background;
    }

    // Startar UI:t
    await initApp(background)
}

I slutet startar vi renderingen av applikationens gränssnitt. Det här är en React-applikation. Bakgrundsobjektet överförs helt enkelt med props. För korrekthetens skull borde man göra en separat tjänst för metoder och lagra tillståndet, men inom ramen för denna artikel är det tillräckligt:

import {render} from 'react-dom'
import App from '.\/App'
import React from "react";

// Initierar applikationen med bakgrundsobjektet som props
export async function initApp(background){
    render(
        <App background={background} />,
        document.getElementById('app-content')
    );
}

Med mobx är det mycket enkelt att starta renderingen vid databasändringar. Vi sätter bara dekoren observer från paketet mobx-react till komponenten, och rendering kommer automatiskt att kallas när några observable som komponenten refererar till ändras. Ingen mapStateToProps eller connect behövs, som i redux. Allt fungerar direkt 'ur lådan':

import React, {Component, Fragment} from 'react'
import {observer} from "mobx-react";
import Init from '.\/components\/Initialize'
import Keys from '.\/components\/Keys'
import Sign from '.\/components\/Sign'
import Unlock from '.\/components\/Unlock'

@observer \/\/ Komponenten med denna dekoration kommer automatiskt att anropa render-metoden om de observerbara som den hänvisar till ändras
export default class App extends Component {

    \/\/ Det är korrekt att extrahera logiken för att rendera sidor till routing och inte använda inbäddade ternära operatorer,
    \/\/ samt koppla observerbara och metoder till bakgrunden direkt till de komponenter som använder dem
    render() {
        const {keys, messages, initialized, locked} = this.props.background.state;
        const {lock, unlock, addKey, removeKey, initVault, deleteVault, approve, reject} = this.props.background;

        return <fragment>
            {!initialized
                ?
                <init oninit="{initVault}/">
                :
                locked
                    ?
                    <unlock onunlock="{unlock}/">
                    :
                    messages.length &gt; 0
                        ?
                        <sign keys="{keys}" message="{messages[messages.length" - 1]} onapprove="{approve}" onreject="{reject}/">
                        :
                        <keys keys="{keys}" onadd="{addKey}" onremove="{removeKey}/">
            }
            <div>
                {!locked &amp;&amp; <button onclick="{()" > lock()}&gt;Lås App</button>}
                {initialized &amp;&amp; <button onclick="{()" > deleteVault()}&gt;Radera alla nycklar och initiera</button>}
            </div>
        </Fragment>
    }
}

Övriga komponenter kan ses i koden i mappen UI.

Nu måste klassen för applikationen göra en selektor för tillståndet för UI och meddela UI vid förändring. För detta kommer vi att lägga till metoden getState och reaction, som anropar remote.updateState:

import {action, observable, reaction} from 'mobx';
import uuid from 'uuid/v4';
import {signTx} from '@waves/waves-transactions'
import {setupDnode} from './utils/setupDnode';
import {decrypt, encrypt} from './utils/cryptoUtils';

export class SignerApp {

    ...

    // offentlig
    getState() {
        return {
            keys: this.store.keys,
            messages: this.store.newMessages,
            initialized: this.store.initialized,
            locked: this.store.locked
        }
    }

    ...

    //
    connectPopup(connectionStream) {
        const api = this.popupApi();
        const dnode = setupDnode(connectionStream, api);

        dnode.once('remote', (remote) => {
            // Skapa reaction på förändringar av tillståndet, som gör ett anrop till en fjärrprocedur och uppdaterar tillståndet i UI-processen.
            const updateStateReaction = reaction(
                () => this.getState(),
                (state) => remote.updateState(state),
                // Tredje argumentet kan användas för att överföra parametrar. fireImmediately betyder att reaction kommer att köras första gången direkt.
                // Detta är nödvändigt för att få det initiala tillståndet. Delay tillåter att ställa in debounce.
                {fireImmediately: true, delay: 500}
            );
            // Ta bort prenumerationen när klienten kopplas bort
            dnode.once('end', () => updateStateReaction.dispose())

        })
    }

    ...
}

Vid mottagning av objektet remote skapas reaction på förändring av tillståndet, som anropar funktionen på UI-sidan.

Sista handen - vi lägger till en visning av nya meddelanden på ikonen för tillägget:

function setupApp() {
...

    // Reaction på att ställa in texten på badgen.
    reaction(
        () => app.store.newMessages.length > 0 ? app.store.newMessages.length.toString() : '',
        text => extensionApi.browserAction.setBadgeText({text}),
        {fireImmediately: true}
    );

...
}

Så applikationen är klar. Webbplatser kan begära signaturer av transaktioner:

Koden finns tillgänglig på denna länken.

Slutsats

Om du har läst artikeln till slutet men har frågor kan du ställa dem i förrådet med tillägget. Där hittar du även commits för varje angiven steg.

Och om du är intresserad av att se koden för ett riktigt tillägg, så kan du hitta detta här.

Koden, förrådet och beskrivningen av arbetet från siemarell

Källa: habr.com