Uživatelé, role a firmy na Facebooku

květen 10 2019

Administrace a oprávnění na Facebooku nejsou úplně triviální, zvlášť dokud si nesáhnete úplně na každou situaci a roli. Tento zápisek je pokusem o co nejstručnější vysvětlení principů.

Osobní účet a Firma:

Při registraci do Facebooku se automaticky vytvoří Osobní účet. Pro veškerou práci s Facebookem už není potřeba vytvářet žádné další přihlašovací údaje. Rozšíření na Firmy i Reklamní účty už jde zakládat prostřednictvím Vaší osoby.

Osobní účet (tj. Vy) může být součástí jedné nebo více Firem. Ve Firmě jsem buď admin nebo zaměstnanec. Admin nastavuje Firmu a přiděluje pravomoce uvnitř Firmy, zaměstnanec může Firmu jen opustit.

Firma buď vlastní nebo dostává přístupy ke Stránkám a Reklamním účtům. Administrátoři Firmy mohou libovolně přidělovat oprávnění zaměstnancům na všech stránkách a reklamních účtech, ke kterým se Firma dostane. Maximální úroveň oprávnění, které může admin přidělit závisí na tom, jaké přístupy dostala Firma. Z toho plyne, že pokud Firma stránku vlastní, může její admin přidělit maximální možný přístup.

Používání Firmy:

Pokud jsem členem Firmy a dostal jsem v jejím rámci oprávnění k nějaké Stránce, přibude mi tato Stránka na Facebooku a mohu ji upravovat. Na venek ale nikdo nepozná, že změny dělám konkrétně já. Dovnitř Firmy vidí jen její členové. To, jestli se můj účet právě chová jako Firma nebo jako Osobní účet, poznám podle domény, na které se nacházím. Na webu www.facebook.com jsem jen základní osoba. Na business.facebook.com se můj účet chová jako právě vybraná Firma a já mám administrativní možnosti podle mojí role v této Firmě. Pokud nejsem členem žádné Firmy, můžu ji vstupem na business.facebook.com založit.

Partnerské Firmy:

Firma A může nasdílet některé své účty a stránky Firmě B. Udělat to mohou administrátoři Firmy A tak, že přidají Firmu B jako partnera ve svém firemním Business Manageru, tj. administrační sekci Firmy.

Stránka a její vlastnictví:

Facebooková Stránka může být vlastněna buď Osobním účtem nebo Firmou. Vlastník je automaticky ten, kdo ji založil. Vlastnictví jde převést z Osobního účtu na Firmu ale ne obráceně. Převést jde také z Firmy A na Firmu B. Vlastník je vždy jen jeden.

Kromě vlastníka jde u Stránky přidělit role také dalším uživatelům. Jsou to:

  • Admin = práva na všechno kromě změny vlastnictví.
  • Editor = práva na úpravu nastavení informací o stránce a přidávání příspěvků, nemůže nastavovat uživatelské role.
  • Moderator = práva na mazání komentářů a moderování diskuzí.
  • Advertiser = Může ve jménu stránky dělat reklamu nebo boostovat příspěvky.
  • Analyst = Může číst statistiky o výkonu stránky.

Reklamní účet:

Ke tvorbě reklamy je potřeba vytvořit Reklamní účet. Jsou dva typy, podle toho, kdo ho založil: osobní a firemní. Osobní reklamní účet nejde sdílet na nikoho dalšího, jde u něj ale převést vlastnictví na Firmu, pokud jsem zároveň administrátorem této Firmy. Reklamu ale z Osobního reklamního účtu mohu dělat na libovolnou stránku, kde k tomu mám dostatečné oprávnění.

Firemní reklamní účet je potřeba založit adminem Firmy. Mohu u něj sdílet oprávnění svým zaměstnancům a prostřednictvím Partnerství jej mohu sdílet i do ostatních Firem. Nemohu jej sdílet s Osobními účty. Také Firemní reklamní účet rozlišuje různé role:

  • Správa účtu = Právo na nastavování fakturace a platebních metod a všecho ostatní.
  • Správa kampaní = Právo na tvorbu reklamních kampaní a boostování příspěvků. Na tvorbu reklamy pro danou Stránku u ní musím mít navíc také alespoň roli Advertiser.
  • Čtení výsledků = právo na čtení výsledků reklamy.

Komplikace všeho s Instagramem:

Aby nic nebylo jednoduché, tak Facebook koupil Instagram a prapodivným způsobem propojil jejich administrace a účty.

Vlastníkem Facebook stránky tak může být nejen Osobní účet a Firma, ale také Instagramový profil. Instagramový profil se na přehledu rolí u stránky zobrazuje úplně stejně jako Firma, stejně tak také skrývá své uživatelské role uvnitř. Externí admin tak nepozná, co to je vlastně za typ účtu.

Jako u Firem i zde platí, že stránku ve vlastnictví Instagramového profilu už nejde převést zpátky na Osobní účet. Jde ji tak uvést do stavu, kdy se majitele už nejde zbavit, aniž by byla založena Firma a stránka navlastněna touto Firmou.

Certbot fails renewal with http-01 challenge on NGINX: Connection refused

dub 14 2019

The problem

This has been bothering me for more than half of a year. You might be unable to automatically renew certificates if the following conditions are true:

  • You're using the python-certbot-nginx plugin to install certificates and handle their renewal on your webserver.
  • You're using different location for acme-challenge than the actual folder inside installation root - this is most likely if you're using NGINX as a proxy for a different service.

During the renewal process you will most likely receive the following error:

Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected error: Failed authorization procedure. example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://www.example.com/.well-known/acme-challenge/1hDMJJfjSOPJENxVmuXdDiphrVlEgRGXfHWB7Z8: Connection refused

However testing the connection with curl or wget from any location predictably gives just a 404 error. To fix it, I had to delete the old certificate configuration and reinstall it with the certbot-nginx plugin each time. This would allow http-01 challenge to pass successfully.

After pulling my hair for a while and playing with the --dry-run option, I've finally noticed the following message:

Plugins selected: Authenticator webroot, Installer nginx

This is wrong. It should be:

Plugins selected: Authenticator nginx, Installer nginx

The reason for the failure appears to be the alternate acme-challenge folder location. Webroot authenticator doesn't handle it and it will attempt to verify using regular sub-folder in webroot.

The solution

Open /etc/cron.d/certbot file and add --nginx option to the renew command, the python-certbot-nginx should be adding it automatically but it doesn't.

Přátelské upozornění od Facebook

dub 05 2019

S Facebookem obecně nerad sdílím jakékoliv informace v míře větší, než je minimum nutné pro fungování. Jednou z takových neposkytnutých informací bylo do nedávna moje telefonní číslo. Nicméně už objevili metodu, jak mě donutit prozradit jim ho:

Kamarád Facebook

A k čemu vlastně potřebuje Facebook tak přesně poznat, že jsem to skutečně já (a kde se nacházím)? To je vedlejší, je to prostě v zájmu veřejného blaha. Teď si určitě můžou být jisti, že mi nějaký hacker nezcizil účet :)

Cassandra Reaper

bře 18 2019

Do WebMedea jsme letos zapojili nové datacentrum. Udržovat Cassandru synchronizovanou pro nás ale s jeho přidáním znamená lineární nárůst práce. Kontroly logů, zda některá tabulka či schéma neprošly opravou, už nejsou časově únosné. Opravy databáze jsme se proto rozhodli automatizovat. Při rešerši možných řešení Pepa objevil aplikaci Cassandra Reaper, jejíž popis nádherně plní všechny naše potřeby:

  • periodické spouštění oprav
  • segmentované běhy oprav
  • historie a výsledek jednotlivých běhů.

Po menších obtížích s konfigurací webového UI jsme ji úspěšně nasadili k testování v následujících týdnech.

Změna schéma WebMedea databáze

led 27 2019

WebMedea již eviduje přes miliardu odkazů mezi weby. Tato data v naší Cassandra databázi zabírají již přes 110 GB. Společně s rostoucím množstvím dat jsme narazili na neustále se zvyšující vytížení RAM, CPU a diskové IO našich serverů právě od Cassandry. Její požadavky se zdá, že nejde ukojit. To nás přivedlo k zamyšlení se nad naším současným datovým modelem. Zhodnotili jsme, že nám nezbývá nic jiného než upravit způsob, jakým WebMedea ukládá odkazy mezi weby.

Cassandra, stejně jako relační databáze, umožňuje ukládat jako primární klíč tabulky skupinu více sloupců. Takový primární klíč se u Cassandry nazývá kompozitní (Composite key) a rozlišuje se na dvě důležité části - oddílový (Partition key) a třídící klíč (Clustering key). Oddílový klíč říká Cassandře do jakých celků (oddílů) ukládat bloky dat - tyto oddíly jsou vytvářeny na základě hodnoty sloupců, které jsou součástí klíče a cílem je vyhnout se příliš malým (stovky záznamů) nebo naopak příliš velkým oddílům (stovky MB dat). Třídící klíč, jak můj pokus o překlad napovídá, pak slouží ke třídění dat v rámci jednoho oddílu.

Při ukládání odkazů ve WebMedea jsme preventivně rozdělili cílové domény odkazů na jednotlivé úrovně oddělené tečkou a v oddílovém klíči je vedeme jako samostatné sloupce. Ukazuje se nám ale, že to nestačí. Největší české weby jako Heuréka.cz a Nova.cz jsou schopny vytvářet v naší databázi oddíly do velikosti až několika GB. Jejich "mikrostránky" jako produktroku.cz pak nejsou daleko pozadu.

Abychom předešli tomuto problému upravujeme náš oddílový klíč aby obsahoval také údaje o datumu nalezení odkazu. Tato změna má navíc benefit v tom, že urychlí zobrazování nejnovějších odkazů na výstupu z WebMedea. Jak ale provést takový zásah do 110 GB dat, která jsou neustále upravována, rozšiřována a čtena našimi klienty?

Pro tento úkol jsme přidali do WebMedea dva nové servery, které sídlí v datacentru Wedosu v Hluboké nad Vltavou. Tyto servery na svých instancích Cassandry replikují pouze nově vytvořené databázové schéma a s ním i novou strukturu uložení odkazů. Původní formát odkazů je postupně překládán na nový persistentní službou. Tím se zvedá zátěž na naše servery v ostrém provozu jen minimálně, protože nemusí zapisovat novou strukturu dat. Paralelně k tomu upravujeme naši těžbu odkazů tak, aby ukládala do obou formátů naráz. Posledním krokem pak bude přepnutí schématu v klientských aplikacích a změna replikačního faktoru nového schématu, aby se nový formát dat rozšířil do celé sítě WebMedea.