System licencji dla aplikacji: konta, licencje i REST API

System licencji dla aplikacji składa się z czterech elementów. Są to konta użytkowników i licencje przypisane do konta i konkretnej aplikacji, z datą ważności. Do tego dochodzi REST API (interfejs, przez który aplikacja łączy się z serwerem), przez które aplikacja sprawdza licencję przy logowaniu. Czwarty element to panele dla osób, które licencje przydzielają i kupują. Tak zbudowaliśmy INVENTA Licenses, centralny system użytkowników i licencji dla aplikacji VR do szkolenia pracowników. Aplikacje tworzy start-up INVENTA XR. Poniżej opisujemy decyzje, które trzeba podjąć przy takim systemie, i to, jak wyglądały w tym projekcie.

Kiedy aplikacja potrzebuje własnego systemu licencji?

Prosta aplikacja sprzedawana bezpośrednio klientom często poradzi sobie z kluczem licencyjnym albo z subskrypcją w bramce płatności. Własny system licencji ma sens, gdy:

• licencje sprzedają pośrednicy (dystrybutorzy, partnerzy, resellerzy) i to oni zakładają konta klientom,
• jeden klient korzysta z kilku aplikacji, a każda ma osobną licencję i osobną datę ważności,
• aplikacje działają poza przeglądarką (na komputerach, goglach VR, urządzeniach) i muszą sprawdzać uprawnienia przez API,
• klient potrzebuje miejsca, w którym zobaczy swoje licencje i poprosi o nowe.

W INVENTA Licenses spełnione są wszystkie cztery warunki. Aplikacje VR działają w systemie Windows, a licencje czasowe przydzielają dystrybutorzy. Klienci logują się w aplikacjach na konta założone przez dystrybutora. Takie systemy budujemy w ramach usługi platformy SaaS i MVP.

Model danych systemu licencji

Obiekt	Co przechowuje	Na co uważać
Aplikacja	nazwa, opis, dostępność	aplikacje dochodzą z czasem, więc listy nie można zaszyć w kodzie
Dystrybutor	dane firmy, przypisani klienci	dystrybutor widzi tylko swoich klientów
Klient (konto)	dane logowania, przypisany dystrybutor	konto zakłada dystrybutor, nie klient
Licencja	klient, aplikacja, data rozpoczęcia i końca	licencja dotyczy jednej konkretnej aplikacji
Prośba o licencję	klient, aplikacja, stan obsługi	ślad, kto i kiedy prosił

Najważniejsza decyzja to przypisanie licencji do pary „konto + aplikacja”. Licencja przypisana do samego konta byłaby prostsza na start. Przy pierwszej nowej aplikacji wymagałaby jednak przebudowy modelu i migracji danych.

Role w systemie licencji

INVENTA Licenses ma trzy panele: administratora, dystrybutora i klienta.

• Administrator zarządza aplikacjami, dystrybutorami i kontami.
• Dystrybutor przydziela swoim klientom licencje czasowe do poszczególnych aplikacji.
• Klient loguje się do systemu, przegląda dostępne aplikacje i ważność licencji oraz prosi o nowe licencje. Korzysta też z FAQ i formularza kontaktowego.

Przy takim podziale najważniejsza jest izolacja danych. Dystrybutor nie może zobaczyć klientów innego dystrybutora, nawet jeśli zmieni identyfikator w adresie strony. Uprawnienia sprawdzamy więc po stronie serwera przy każdym zapytaniu. Ukrycie przycisków w interfejsie nie wystarczy.

Jak aplikacja sprawdza licencję przez REST API?

Przepływ jest prosty. Użytkownik loguje się w aplikacji VR, a aplikacja wysyła dane logowania do API systemu licencji. API odpowiada, czy konto istnieje i czy licencja na tę aplikację jest ważna.

Kilka zasad, które warto przyjąć przy projektowaniu takiego API:

• Odpowiedź rozróżnia przyczyny. „Nieprawidłowe hasło”, „brak licencji na tę aplikację” i „licencja wygasła” to trzy różne komunikaty dla użytkownika. Każdy oznacza inną sprawę do wyjaśnienia z dystrybutorem.
• O ważności decyduje czas serwera. Zegar na komputerze użytkownika można przestawić, więc aplikacja nie powinna sama porównywać dat.
• API ma numer wersji. Aplikacji zainstalowanych na komputerach klientów nie zaktualizujesz jednocześnie. Starsze wersje muszą działać, dopóki ktoś z nich korzysta.
• Połączenie idzie tylko przez HTTPS, a liczba prób logowania jest ograniczona, żeby utrudnić zgadywanie haseł.

Co, gdy aplikacja nie ma połączenia z internetem?

Są trzy typowe warianty. Wybór trzeba podjąć na samym początku projektu, bo od niego zależy architektura.

Wariant	Jak działa	Kiedy pasuje
Wymagane połączenie	bez odpowiedzi API aplikacja się nie uruchomi	aplikacje używane tam, gdzie internet jest pewny
Okres karencji	aplikacja pamięta ostatnie udane sprawdzenie i działa jeszcze przez ustalony czas	krótkie przerwy w łączności
Licencja offline	podpisany plik lub token z datą ważności, weryfikowany lokalnie	stanowiska bez dostępu do sieci

Każdy wariant to kompromis między wygodą użytkownika a kontrolą nad licencjami. W zakładach przemysłowych dostęp do sieci na stanowisku szkoleniowym nie zawsze jest oczywisty. Tę decyzję warto więc omówić z osobami, które znają miejsca, gdzie aplikacje będą używane.

Licencje czasowe w praktyce

• Strefa czasowa daty końca ma znaczenie. Zapis „licencja do 31 marca” powinien oznaczać ten sam moment dla dystrybutora i dla aplikacji.
• Przedłużenie nie może tworzyć przerwy ani straty. Nowa licencja przydzielona przed końcem starej nie może skracać okresu, za który klient już zapłacił.
• Historia zmian pokazuje, kto i kiedy przydzielił, przedłużył lub cofnął licencję. Przy sporach z klientem to jedyne źródło prawdy.
• Klient powinien sam widzieć datę końca licencji. Wtedy rzadziej jest zaskoczony blokadą aplikacji.

Technologia INVENTA Licenses

System działa na Next.js i React z TypeScriptem, z bazą PostgreSQL i interfejsem w Tailwind CSS. Działa w kontenerach Docker za serwerem Nginx. Tych samych technologii używamy w innych realizacjach, co ułatwia utrzymanie. Co zapisać w umowie utrzymania takiego systemu, piszemy we wpisie o umowie utrzymania aplikacji.

System licencji to dobry kandydat na element pierwszej wersji produktu, jeśli model sprzedaży od początku opiera się na pośrednikach. Więcej o wyznaczaniu zakresu piszemy we wpisie MVP dla startupu.

Jeśli sprzedajesz aplikację przez partnerów albo chcesz kontrolować dostęp do kilku aplikacji z jednego miejsca, napisz do nas. Zaczniemy od modelu sprzedaży, a dopiero potem przejdziemy do API.