malja / dezi Goto Github PK

Během reportování je v API možnost odeslat krátký komentář s odůvodněním.

Ani na serveru ani na klientovi není tato možnost využita. Nevidím pro ní ani důvod. Každé nahlášení bude prověřeno na serveru a komentář není třeba.

Jako ochrana před zneužíváním veřejného API budou zavedeny API klíče. Ty budou sloužit jako identifikátor každé instalované instance. Vůči tomuto identifikátoru se pak budou počítat veškeré dotazy na API. Pokud přesáhnout určité množství, budou odmítnuty.

Pro implementaci jsou nutné následující kroky:

1. Vytvořit nový endpoint na serveru, který poskytne klientovi API klíč.
2. Uložit API klíč na klientovi a poté jej odesílat s každým dalším požadavkem na server.
3. Kontrolovat informace o limitech, které budou nově součástí každé odpovědi od serveru. Pokud je dosaženo limitů, musí dojít k přeplánování aktualizací (pokud jsou potřeba). Pokud jsou limity dosaženy uživatelskými akcemi (report), uživatel bude upozorněn.

Nový vzhled přijímané zprávy:

{
    "status": {
        "error": false,
        "message": "No Error",
        "limits": {
            "limit": 10,
            "remaining": 8,
            "reset": 1570433705
        }
    }
}

Přibyla nová položka limits s informacemi o API limitech. Obsahuje:

• limit - Maximální počet požadavků za hodinu.
• remaining - Počet zbývajících dotazů.
• reset - Timestamp, kdy dojde k resetu limitů.

Aktuálně nejsou ošetřeny případy, kdy server neodpoví, nebo odpoví ve špatném formátu. Je třeba tyto výjimečné události v klientovi ošetřit.

Implementovat jednotný postup "matchování" adres. Obyčejné porovnání není možné.

Vytvořit GUI pro popup.

Aktuálně se z API vypisuje pro každý web jeden objekt s následujícím formátem:

{
    "url": "*my.website.com*",
    "id": 1,
    "reasons": [
       "Jeden", "Dva", 
   ]
}

Tento formát je pro testování a teoreticky i další fungování dostatečný. Silně ale odpovídá formátu, v jakém jsou data uložena na serveru.

To má následující dopady:

• ID je stejné jako záznam v databázi. Ve zprávě sloužil ke konstrukci odkazu na web projektu, kde bude více informací.
• URL obsahuje přímo řetězec pro "match" s placeholdery.
• REASONS - je pole obsahující seznam krátkých důvodů v češtině proč byl web zařazen na seznam. To znemožňuje překlad na klientovi.

Proto navrhuji následující nový formát:

{
    "website": "my.website.com",
    "links": [
        "*my.website.com*", "*friendly.website.com*"
    ],
    "reasons": [
        "reasonIdOne", "reasonIdTwo"
    ]
}

Kde:

• WEBSITE - je hlavní odkaz na stránku. Bude použit jako název "zastřešující" všechny odkazy spadající pod tento web. Místo ID záznamu bude pro vytvoření odkazu na web projektu použito právě toto pole.
• LINKS - je seznam odkazů patřící pod tento web a které mají být zablokovány.
• REASONS - je nově seznam identifikátorů, které budou použity pro překlad přímo na klientovi. Díky tomu je možné přímo na klientovi přidat k jednotlivým důvodům i krátký popis.

Na dezinformačním webu by se ikona doplňku měla měnit: https://developer.chrome.com/extensions/browserAction#method-setBadgeText

Uživatel si musí moci vybrat, že nechce pro daný web upozornění už dostávat. Stejně tak po zavření upozornění musí být další upozornění zobrazeno až za určitý čas.

Koupit doménu a rozjet web.

Implementovat merge lokální databáze a nově stažené.

Vytvořit ikonu doplňku.

Vytvořit lepší GUI pro popup browser actionu