Przejdź do treści
Wszystkie wpisy
Blog

Lista kontrolna white-label: o co pytać dostawcę po wgraniu logo

White-label to nie wgranie logo. Pytania o domeny, domeny nadawcze, linki do resetu hasła, dziedziczenie i o to, co zdradza źródło strony.

The Lurno teamAugmental11 min czytania

White-labeling zawodzi w miejscach, których nikt nie pokazuje na demo. Wgranie logo działa zawsze. O tym, czy pracownicy klienta mogą przez rok korzystać z platformy, nie natykając się na nazwę Państwa dostawcy, decydują: host wewnątrz linku do resetu hasła, domena, która podpisała powiadomienie e-mail, tekst w karcie przeglądarki oraz strona logowania, na którą ktoś trafia na zimno o 8 rano, zanim istnieje jakakolwiek sesja. O te cztery rzeczy proszę zapytać, zanim zapytają Państwo o kolory.

Na pytanie „czy wspierają Państwo white-labeling” każdy dostawca odpowiada twierdząco. Słowo obejmuje wszystko od kodu koloru po tenanta naprawdę należącego do Państwa, a obie odpowiedzi przychodzą tym samym pewnym siebie tonem. Dalej jest lista kontrolna na rozmowę, spisana jako pytania, a nie funkcje: lista funkcji zaprasza do potwierdzenia, pytanie zaprasza do pokazania.

White-labeling

Udostępnianie platformy pod własną nazwą, własną domeną i własnym projektem graficznym, tak by korzystający z niej ludzie nie mieli szczególnego powodu wiedzieć, kto ją zbudował. Motyw graficzny jest podzbiorem: kolory, kroje pisma i logo na stronach, które widzi zalogowany użytkownik. White-labeling to cała powierzchnia — pasek adresu, nagłówki poczty, strona logowania, karta przeglądarki, źródło strony. Motyw graficzny to konfiguracja; white-labeling jest w większości architekturą.

Użytecznym testem nie jest to, czy pojawia się logo klienta. Jest nim to, czy którykolwiek moment zwykłego tygodnia — logowanie, reset hasła, otwarcie wiadomości, wklejenie linku do zgłoszenia — wydobywa na wierzch nazwę dostawcy. Proszę przejść ten tydzień na głos podczas rozmowy.

Lurno

Pracownik klienta loguje się w domenie swojego pracodawcy, dostaje pocztę podpisaną domeną swojego pracodawcy i wkleja link do wsparcia, w którym widnieje nazwa jego pracodawcy.

Not this

Logo i kod koloru na produkcie, który nadal mieszka pod yourcompany.vendor.com i wysyła pocztę z no-reply@vendor.com.

Domena i te fragmenty sesji, które ją opuszczają

Własna domena jest elementem nośnym; cała reszta to dekoracja na niej. Pięć pytań załatwia większość sprawy.

  • Czy własna domena mieści się w wycenianym dla nas planie, czy jest dodatkiem? Proszę poprosić o konkretną pozycję na fakturze. Domeny to częsty element dosprzedaży, a na starszych platformach raczej zadanie dla usług wdrożeniowych niż ustawienie.
  • Kto wystawia certyfikat TLS i co się dzieje przy jego odnowieniu? Automatyczne wystawienie i automatyczne odnowienie albo zgłoszenie co kilka miesięcy. Proszę zapytać, co zobaczy uczestnik tego ranka, gdy odnowienie się nie powiedzie.
  • Jedna domena na konto czy jedna na organizację? Jeśli prowadzą Państwo kilka akademii klienckich albo kampusów, proszę zapytać, na jakiej głębokości osobna nazwa hosta przestaje być możliwa.
  • Czy możemy skonfigurować to sami? Dobrą odpowiedzią jest ekran pokazujący dokładne rekordy DNS do wprowadzenia u Państwa rejestratora oraz status na żywo w trakcie wystawiania certyfikatu. Sygnałem ostrzegawczym jest wątek mailowy z działem wsparcia.
  • Które fragmenty sesji opuszczają naszą domenę? Pobierane pliki, wideo, odtwarzacz sprawdzianów, weryfikacja certyfikatu, osadzony widget pomocy, przekazanie sesji przy logowaniu. Proszę poprosić o otwarcie zakładki sieci na działającym tenancie i odczytanie nazw hostów na głos.

Czy uczestnicy zobaczą kiedykolwiek domenę dostawcy, jeśli mamy własną domenę?

Zwykle gdzieś tak, a pytanie brzmi: gdzie. Typowe przecieki to przekierowanie w trakcie logowania, multimedia serwowane ze wspólnego CDN, strona, do której prowadzi link weryfikacyjny certyfikatu, oraz każdy osadzony widget czatu. Każdy z nich wynika ze sposobu, w jaki platforma została zbudowana, i każdy jest widoczny dla uczestnika, więc proszę pytać o nie z nazwy.

Poczta to ta połowa white-labelingu, która po cichu zostaje przy dostawcy. Adres w polu From to ciąg wyświetlany i każdy może go ustawić. To, co program pocztowy czyta pod spodem, to domena, która naprawdę podpisała wiadomość.

From: Northbridge Academy <no-reply@learn.northbridge.edu>   <- the display line
Return-Path: bounces@mail.vendor-lms.com                     <- the envelope sender
DKIM-Signature: ... d=vendor-lms.com ...                     <- the signing domain

Gmail dopisuje przy nadawcy małe „via vendor-lms.com”, gdy domena podpisująca nie zgadza się z domeną z pola From. Dział IT Państwa klienta wie, co to znaczy. Zatem proszę zapytać:

  • Które wiadomości wychodzą z naszej domeny, a które z Państwa? Proszę poprosić o pełną listę — zaproszenie, powitanie, reset hasła, zapis, przypomnienie, opublikowana ocena, wystawiony certyfikat, podsumowanie, alert administracyjny — a potem o to, które z nich mogą nieść naszego nadawcę.
  • Samo pole From czy także domena podpisująca? Pytaniem uzupełniającym jest to, które rekordy DNS Państwo publikują. Jeśli żaden z nich nie trafia do Państwa rejestratora, poczta tak naprawdę nie wychodzi z Państwa domeny.
  • Nasze własne konto nadawcze i własny klucz czy Państwa wspólna pula? We wspólnej puli współczynnik odrzuceń innego tenanta staje się, niewidocznie, Państwa problemem z dostarczalnością.
  • Osobno dla każdej organizacji czy raz na samej górze? Jeden nadawca dla całego konta unieważnia całą niezależność przy pierwszej wiadomości.
  • Którego logo używa wiadomość i gdzie jest ono hostowane? Obrazek hostowany u dostawcy pokazuje swój adres URL w tekście alternatywnym za każdym razem, gdy brama pocztowa blokuje zdalne obrazy.

Dalej link w środku wiadomości, na którym większość ocen poznaje prawdę. Treść może nieść Państwa logo, kolory i nadawcę, a przycisk pośrodku i tak może wskazywać na host dostawcy — bo linki do zaproszeń i do resetu haseł są zwykle wytwarzane przez warstwę uwierzytelniania, skonfigurowaną raz, globalnie, z jednym adresem witryny.

Czy wiadomości z resetem hasła i z zaproszeniem korzystają z mojej własnej domeny?

Często nie, nawet na platformach, które resztę brandują dobrze, i to najczęstsze miejsce, w którym maska się zsuwa. Te linki są zwykle generowane z jednego, globalnie skonfigurowanego adresu witryny, więc wiadomość może wyglądać całkowicie na Państwa, podczas gdy link w środku prowadzi do hosta dostawcy. O to akurat proszę nie pytać — proszę to sprawdzić i samodzielnie odczytać cel linku oraz nagłówki.

Strona logowania jest najtrudniejszą stroną do zbrandowania i pierwszą, którą widzi każdy uczestnik. Zanim ktokolwiek się uwierzytelni, platforma nie wie o odwiedzającym nic poza nazwą hosta, pod którą przyszedł. Jeśli identyfikacja wizualna ładuje się z organizacji zalogowanego użytkownika, odwiedzający na zimno dostaje domyślny wygląd dostawcy. Proszę zapytać dokładnie tymi słowami: czy identyfikacja wizualna jest rozstrzygana na podstawie samej nazwy hosta, zanim istnieje jakakolwiek sesja?

  • Co renderuje się w naszej domenie dla odwiedzającego bez sesji? Logo, nazwa produktu, kolory, tło, treść napisu na przycisku logowania.
  • Czy jest wiersz „powered by” i co go usuwa? Przełącznik, wyższy plan albo zapis w umowie. Wszystkie trzy istnieją i każde kosztuje inaczej.
  • Jak wyglądają stany błędu? Złe hasło, wygasłe zaproszenie, zablokowane konto — strony, które najpewniej są domyślnymi szablonami dostawcy, i te, które sfrustrowany użytkownik czyta najuważniej.
  • Co jest w karcie przeglądarki? Tytuł strony na każdej ścieżce oraz favicon. Proszę zapytać, czy favicon jest osobny dla każdej organizacji, czy jest jednym plikiem dla całej platformy; serwowanie go ze stałej ścieżki statycznej to częste pójście na skróty.
  • Czy są dwa logo? Logo na tryb jasny, logo na tryb ciemny, zwykle także kwadratowy znak. Proszę zapytać, co się stanie, jeśli wgrają Państwo jedno, a użytkownik przełączy się na tryb ciemny.
  • Co jest w dokumentach opuszczających platformę? PDF-y certyfikatów, wyeksportowane raporty, wykazy wyników. Proszę sprawdzić stopkę, a potem metadane pliku, gdzie nazwa dostawcy przeżywa najdłużej.

Dziedziczenie i jego ziarnistość

Jeśli prowadzą Państwo więcej niż jedną organizację — firmy klienckie, szkoły w grupie, spółki krajowe — pytanie „czy identyfikacja wizualna się dziedziczy?” jest pytaniem o ziarnistość, a nie o tak lub nie, i to właśnie na ziarnistości praca albo znika, albo się mnoży.

  • Jeśli organizacja podrzędna nie ustawi nic, co dostaje? Markę rodzica albo domyślny wygląd dostawcy. Dla grupy to drugie jest błędem: każda nowa szkoła zaczyna życie, wyglądając jak dostawca.
  • Wszystko albo nic, czy pole po polu? Szkoła, która chce palety grupy i własnego godła, potrzebuje dziedziczenia na poziomie pojedynczego pola. Dziedziczenie całym blokiem zmusza każde dziecko do powtórzenia czternastu kolorów po to, by zmienić jedno logo.
  • Czy logo jasne i ciemne dziedziczą się jako para? Jeśli dziedziczą się niezależnie, dziecko, które wgra tylko jasne logo, zostawia ciemne logo rodzica osamotnione na tle nowej palety. Drobne pytanie, po którym zapada pouczająca cisza.
  • Kto ma prawo to zmieniać? Własny administrator organizacji podrzędnej czy każda zmiana idąca przez Państwa zespół centralny. To drugie to kolejka zgłoszeń, którą będą Państwo obsługiwać jeszcze za rok.
  • Jak głęboko to sięga? Dwa poziomy to standard. Wydawca ze szkołami, które mają kampusy, potrzebuje więcej.
  • Czy dziedziczy się także terminologia, nie tylko wygląd? Jeśli można zmienić nazwę „uczeń” na „kursant”, proszę zapytać, czy spływa to w dół i czy ustawia się to osobno dla każdego języka.

Czy każda podorganizacja może mieć własną identyfikację wizualną i własną domenę, czy tylko konto najwyższego poziomu?

To różni się bardziej niż cokolwiek innego na tej liście i to właśnie oddziela platformę wielodostępną od jednotenantowej z motywami graficznymi. Wiele produktów nadaje markę kontu i daje kontom podrzędnym przefiltrowany widok marki rodzica — w porządku dla działów, źle dla klientów. Proszę zapytać, czy organizacja podrzędna może mieć własną nazwę hosta, własny certyfikat, własną parę logo, własną paletę i własnego nadawcę oraz na jakiej głębokości to się kończy.

Testy do wykonania samodzielnie

Doświadczenie mobilne

Najpierw proszę ustalić, co dokładnie jest Państwu sprzedawane, bo „mamy wersję mobilną” obejmuje dwa produkty o różnych historiach brandingowych. Jeśli jest to aplikacja natywna, pytania są handlowe, a nie kosmetyczne. Czyja nazwa widnieje we wpisie w sklepie? Kto jest właścicielem konta dewelopera i kto zgłasza wydania? Czy jest osobna kompilacja dla każdego klienta, a wraz z nią osobny cykl weryfikacji?

Jeśli jest to responsywna aplikacja webowa, identyfikacja wizualna przechodzi tą samą ścieżką kodu co witryna na komputerze, co zwykle jest tu lepszą odpowiedzią. Proszę poprosić o pokazanie jej na szerokości telefonu w Państwa własnej domenie, a potem zapytać, jaka nazwa i jaka ikona pojawiają się, gdy uczestnik doda ją do ekranu głównego.

Źródło strony

Ktoś w końcu otworzy podgląd źródła — dział IT klienta, ciekawski uczestnik. Nie chodzi o ukrywanie czegokolwiek; chodzi o sprawdzenie, czy platforma została zbudowana tak, by dawać się serwować pod cudzą nazwą. Dwa polecenia odpowiadają na większość tego pytania.

# Czyja nazwa widnieje na certyfikacie serwowanym w Państwa domenie?
openssl s_client -connect learn.yourbrand.com:443 \
  -servername learn.yourbrand.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# Co mówią HTML i nagłówki odpowiedzi?
curl -sL https://learn.yourbrand.com | grep -io 'vendorname' | wc -l
curl -sI https://learn.yourbrand.com | grep -iE 'server|x-powered-by|content-security-policy'

Ciekawsze jest sprawdzenie certyfikatu. Niektóre platformy wystawiają certyfikat na każdą nazwę hosta klienta; inne umieszczają wielu klientów na jednym certyfikacie wielonazwowym. Jeśli lista nazw alternatywnych w domenie Państwa klienta wymienia innych klientów, jest to publiczna informacja o tym, kogo jeszcze obsługuje dostawca, i przegląd bezpieczeństwa ją znajdzie.

W HTML-u proszę odczytać tytuł strony, znacznik `og:site_name`, manifest aplikacji webowej, nazwy hostów, z których ładują się skrypty i obrazy, oraz punkty końcowe analityki i raportowania błędów w nagłówku content security policy. To właśnie te punkty końcowe zdradzają najczęściej, bo nikt nie myśli o nich jak o identyfikacji wizualnej.

Jak poprowadzić rozmowę

  1. Proszę poprosić o działającego tenanta w domenie, którą Państwo kontrolują, a nie o nagrane demo. Dzień pracy z DNS-em jest tańszym testem niż rok umowy.
  2. Proszę poprosić o wysłanie prawdziwego zaproszenia i prawdziwego resetu hasła na adres, który Państwo kontrolują. Proszę odczytać cel linku i nagłówki.
  3. Proszę otworzyć stronę logowania na zimno, w oknie prywatnym, w trybie ciemnym, na telefonie.
  4. Proszę uruchomić powyższe dwa polecenia na własnej nazwie hosta.
  5. Proszę zebrać odpowiedzi we wspólnym dokumencie, z datami. „W budowie” to dobra odpowiedź zapisana na papierze i kiepska odkryta w czwartym miesiącu.

Proszę naciskać na te pytania, po których zamiast odpowiedzi pojawia się pokaz ekranu. Ta reakcja rzadko bywa wymijaniem — zwykle znaczy, że nikt wcześniej o to nie pytał.

Gdzie w tym wszystkim jest Lurno

Nasze własne odpowiedzi, z częściami niedokończonymi włącznie. Domeny są osobne dla każdej organizacji, na dowolnej głębokości drzewa, a ustawia się je w ustawieniach samej tej organizacji: wpisać nazwę hosta, opublikować rekordy DNS, które pokaże ekran, obserwować status, aż certyfikat będzie aktywny, a potem oznaczyć domenę jako główną. Nazwy hostów przechodzą przez Cloudflare; TLS wystawia się i odnawia automatycznie. Strona logowania rozstrzyga logo, tytuł, hasło, motyw i tło na podstawie samej nazwy hosta, zanim ktokolwiek się uwierzytelni. Gdy domena jest już główna, linki z zaproszeniami dla tej organizacji budowane są na niej.

Identyfikacja wizualna to siedemnaście pól — czternaście tokenów kolorystycznych, krój pisma nagłówkowego, krój pisma tekstowego i promień zaokrąglenia narożników — plus jasne logo, ciemne logo, favicon, tytuł i hasło. Dziedziczenie odpowiada na powyższe pytanie o ziarnistość: podorganizacja bez własnego motywu bierze cały motyw rodzica, para logo dziedziczy się jako całość, więc nie da się zostawić ciemnego logo osamotnionego na jasnym tle, a tytuł, hasło i favicon dziedziczą się pole po polu. Terminologię można przemianować osobno dla każdego języka, a powiadomienia e-mail wychodzą z własnej subdomeny organizacji. Pełny model jest na stronie o white-label; kto wysyła pocztę, znajdą Państwo na liście podprocesorów w sekcji bezpieczeństwo.

Luki, powiedziane wprost. Nie ma natywnych aplikacji mobilnych — Lurno jest responsywną aplikacją webową, więc na telefonie identyfikacja wizualna jest ta sama co wszędzie indziej, ale nie ma aplikacji pod Państwa nazwą w żadnym sklepie, a aplikacje natywne są na mapie drogowej, a nie wdrożone. Logowanie jednokrotne SAML i OIDC także jest na mapie drogowej; dziś istnieje logowanie partnerskie, w którym Państwa system przekazuje podpisaną asercję dla uczestnika, którego już uwierzytelnił. Płatności i koszyk są w budowie.

White-labeling nie jest funkcją włączaną przy zakładaniu konta. Jest właściwością tego, gdzie dostawca postawił swoje granice na lata przed Państwa telefonem, a te granice da się odczytać z paska adresu, z nagłówków poczty i ze źródła strony działającego tenanta. Pół godziny z prawdziwą domeną rozstrzyga więcej pozycji z tej listy niż popołudnie rozmów — także naszych, i po to właśnie jest demo.