Motyw i wtyczki pisane na zamówienie mają wersje, wydania i historię zmian dokładnie tak samo jak oprogramowanie publiczne. Nie mają tylko jednego: miejsca, w które zagląda WordPress, sprawdzając, czy jest aktualizacja. Efekt jest znany każdemu, kto utrzymuje kilkanaście serwisów — nowa wersja powstaje w repozytorium, a na stronach pojawia się wtedy, gdy ktoś ręcznie wgra paczkę.
Dlaczego wklejony token jest złym rozwiązaniem
Najczęstsza odpowiedź brzmi: wygenerować osobisty token dostępu i wpisać go do konfiguracji. To działa i dlatego jest tak popularne. Warto jednak zobaczyć, co dokładnie ląduje wtedy w pliku konfiguracyjnym.
Token szeroki na tyle, żeby odczytać jedno prywatne repozytorium, jest szeroki na tyle, żeby zapisać do każdego innego, do którego sięga konto. Leży w pliku otwartym tekstem. Nie wygasa. I należy do osoby — więc przestaje działać, kiedy ta osoba odchodzi z firmy, a działa dalej, kiedy nie odchodzi, choć dostęp już jej się nie należy.
Sekret, który nie wygasa i należy do człowieka, jest problemem organizacyjnym przebranym za ustawienie techniczne.
Aplikacja zamiast osobistego tokenu
Zamiast tokenu prosimy o poświadczenia aplikacji. Osoba wdrażająca zakłada ją sama, przez ekran zgody serwisu hostującego repozytoria — widzi tam dokładny zakres uprawnień i wskazuje, do których repozytoriów aplikacja ma sięgać. Różnica w praktyce wygląda tak:
| Wklejony token | Aplikacja | |
|---|---|---|
| Czas życia | bezterminowo | godzina, odnawiana automatycznie |
| Uprawnienia | zwykle pełny dostęp do repozytoriów | tylko odczyt treści i metadanych |
| Zasięg | wszystko, co widzi konto | tylko wskazane repozytoria |
| Przypisany do | osoby | aplikacji |
Klucz prywatny aplikacji jest szyfrowany, a kluczem szyfrującym są sole kryptograficzne z pliku konfiguracyjnego serwisu. To rozdzielenie ma konkretny skutek: sam zrzut bazy danych nie wystarczy, żeby klucz odzyskać. A zrzuty bazy trafiają do kopii zapasowych i na środowiska testowe, czyli w miejsca o innym poziomie ochrony niż produkcja.
Aktualizacja wygląda jak każda inna
Reszta jest celowo nudna. Nowa wersja pojawia się w panelu jak aktualizacja z katalogu publicznego: ten sam przycisk, te same uprawnienia, ta sama możliwość cofnięcia. Nie budujemy osobnego ekranu „nasze aktualizacje”, bo osoba utrzymująca serwis ma już wyrobiony odruch — i lepiej się w niego wpiąć, niż uczyć jej drugiego.
- Kanały wydań: wersje stabilne, przedpremierowe albo czubek gałęzi rozwojowej.
- Instalacja dowolnej wersji, w tym starszej — bo tym właśnie jest wycofanie zmiany.
- Notatki wydania w panelu, żeby decyzja o aktualizacji nie wymagała otwierania repozytorium.
- Powiadomienie z repozytorium, dzięki któremu wydanie widać w ciągu sekund, a nie po najbliższym odpytaniu.
- Ekran zdrowia z konkretnymi liczbami i wskazaniem naprawy tam, gdzie naprawa istnieje.
Czego to świadomie nie robi
Mechanizm nie przejmuje aktualizacji cudzych wtyczek, dopóki nie zostanie mu to wprost wskazane. Wtyczka z katalogu publicznego ma się aktualizować z katalogu publicznego — przechwycenie tego kanału jest łatwe do napisania i trudne do odkręcenia, kiedy po latach nikt już nie pamięta, dlaczego jedna z wtyczek nie widzi aktualizacji.
Wszystkie wpisy