Wykluczanie danych serializowanych w zewnętrznym bundle’u

Przy projektowaniu API RESTowego nie zawsze chcemy eksponować wszystkie pola modelu. Niech jako przykład posłuży ukrycie wrażliwych danych związanych z użytkownikiem jak np. hasło i adres e-mail. W standardowym przypadku, korzystając z frameworka Symfony oraz FOSRestBundle wystarczy prosta adnotacja w kodzie modelu i odpowiednie dane nie są już więcej eksponowane. Niestety, korzystając z zewnętrznych bibliotek, nie możemy po prostu wstawić adnotacji do kodu, ale musimy skorzystać z konfiguracji, którą prezentuję w niniejszym wpisie.

Problem

Pisząc przy użyciu Symfony, częstym wyborem przy rozwiązaniu kwestii obsługi użytkowników jest użycie FOSUserBundle. Tworzymy encję User, którą można później śmiało wykorzystać w relacji jako np. autor wpisu blogowego, właściciel projektu itp. Przy zwracaniu odpowiedzi RESTowej powoduje to nie lada problem – eksponowane są wrażliwe dane o użytkowniku, takie jak: adres e-mail, hasło, czy sól hasła. Pokazuje to poniższy przykład z aplikacji, którą projektuję:

My chcielibyśmy jednak, żeby takie informacje nie trafiały do wiadomości publicznej. Sęk w tym, że te dane generuje dla (i za) nas klasa FOS\UserBundle\Model\User, więc musimy jakoś poinstruować naszą aplikację, że nie chcemy tych danych widzieć w pliku JSON.

Rozwiązanie

FOSRestBundle wewnętrznie używa JMS Serializera do zamiany obiektów na dane wyjściowe typu JSON, czy XML. Zatem to w konfiguracji serializera będziemy musieli dokonać kilku zmian.

Aby ukryć pewne dane z serializacji, musimy skonfigurować JMS Serializer, tak aby nie przetwarzał niektórych pól. O ile w przypadku własnego kodu jest to dość proste, o tyle zmienienie tego w obcym (3rd party) bundle’u, wymaga nieco pomyślunku.

Na początek dodajmy do pliku app/config.yml konfigurację JMS Serializera.

Właściwość directories określa katalogi, które serializer ma brać pod uwagę jako konfigurację procesu zamiany obiektów w dane tekstowe. Informacje są przekazywane w formie tablicy o dwóch właściwościach – path – katalog, w którym znajdują się pliki konfiguracyjne oraz namespace_prefix – jakiej przestrzeni nazw konfiguracja ma dotyczyć. Zmienna %kernel.root_dir% określa katalog app naszej aplikacji (w zasadzie miejsce, gdzie znajduje się plik AppKernel.php) – jest to o tyle ważne, że pod ścieżką podaną w path musimy umieścić właściwą konfigurację.

W folderze app/Resources tworzymy podkatalogi FOSUserBundle/serializer i w ostatnim umieszczamy plik o nazwie np. Model.User.yml. Standardowo, nazwa powinna jasno sugerować, do czego konfiguracja się odnosi. Zawartość tego pliku prezentuje się następująco.

W pierwszej linii podajemy bezwzględną ścieżkę przestrzeni nazw do klasy, której konfigurację definiujemy. Parametr ALL we właściwości exclusion_policy oznacza, że domyślnie żadne pole nie podlega serializacji. Dopiero później za pomocą właściwości properties kolejno wymieniamy pola (nazwy są zgodne z zapisanymi w modelu) i ustawiamy im właściwość expose na wartość true. Dzięki temu powodujemy, że będą one brane pod uwagę podczas procesu serializacji.

Oczywiście mogliśmy zastosować strategię NONE zamiast ALL, ale wtedy byśmy musieli wykluczać poszczególne pola. Wybór może zależeć od tego, czy więcej danych chcemy ukryć, czy pokazać – zazwyczaj wybieramy tę opcję, która generuje mniej kodu.

Efekt końcowy prezentuje się następująco:

Jak widzimy, efekt jest zadowalający – w wyniku nie mamy już żadnych haseł, czy też innych pól z klasy User, których być może nie chcemy ujawniać.

Więcej informacji

Możliwości konfiguracyjnych jest więcej. Polecam zajrzeć do dokumentacji projektu JMS Serializer, gdzie znajdziemy wszystkie możliwości konfiguracyjne tego projektu. Zamieszam także źródła, o które oparłem ten wpis.

Ubuntu 4.10 po 12. latach

Właśnie ukazał się pierwszy film na moim reaktywowanym kanale YouTube. Na początek wziąłem na tapet pierwsze wydanie chyba najbardziej rozpoznawalnej dystrybucji Linuksa – Ubuntu. Na filmie zaprezentowałem instalację tego systemu na komputerze z okolic 2002 roku. Później pokazałem również kilka aplikacji wchodzących w skład dystrybucji oraz spróbowałem wejść na nowoczesną stronę internetową – wynik można zobaczyć na filmie.

GitLab CE i reverse proxy na Apache

Przy okazji przenosin małego serwera VPS do nowego dostawcy postanowiłem nieco ulepszyć kwestię obsługi oraz śledzenia zmian na repozytoriach Gita. Zacząłem rozglądać się nad oprogramowaniem, które oprócz ładnego podglądu zmian w projekcie da mi coś więcej – ułatwi zarządzanie użytkownikami, doda ochronę gałęzi oraz pozwoli na bieżąco aktualizować podgląd WWW wersji deweloperskiej rozwijanych aplikacji przy każdym pushu do gałęzi develop.

Wstęp

Poprzednio używałem skryptu GitList – wybrany został ze względu na jego prostotę i niechęć do wprowadzania zbędnych rewolucji i gruntownej rekonfiguracji serwera. GitList nie zawierał żadnych mechanizmów autoryzacji (leżało to w kwestii administratora) i pozwalał jedynie na przegląd zmian w istniejącym repozytorium. Zatem rozwiązanie to było dobre na początku pracy z serwerem, kiedy wymagania (i przede wszystkim poziom mojej wiedzy) były niższe.

Interfejs GitList jest bardzo prosty i mało funkcjonalny.
Interfejs GitList jest bardzo prosty i mało funkcjonalny.

Drugą kwestią był podgląd WWW wersji developerskich aplikacji. Poprzednio był to prosty skrypt uruchamiany przez CRON-a codziennie w nocy. Dla nowego serwera zacząłem więc szukać lepszego rozwiązania i, po krótkim, ale w miarę dokładnym researchu, wybór padł na GitLaba Community Edition. Poniżej przedstawiam sposób jego instalacji oraz podstawowej konfiguracji na serwerze z systemem Debian 8.

Instalacja

Na początek wykonamy aktualizację systemu i zainstalujemy wymagane oprogramowanie. Jeżeli pracujemy na serwerze zdalnym, to pakiety openssh-server oraz ca-certificates będą już zainstalowane.

Dalej instalujemy do naszego systemu repozytorium GitLaba. Jest to zalecane rozwiązanie ze względu na okresowe aktualizowanie aplikacji przez jej twórców. Kolejno instalujemy paczkę z programem oraz dokonujemy dokonujemy wstępnej konfiguracji oprogramowania.

Wszystko powinno teraz działać, ale jeżeli na tym samym serwerze działa już jakiś serwer HTTP (np. Apache), nie będziemy w stanie uzyskać dostępu do GitLaba. Dzieje się tak, ponieważ opiera się on o wbudowany serwer nginx, a nie korzysta z oprogramowania systemowego. Z takiej sytuacji mamy dwa wyjścia. Pierwsze – skonfigurować GitLaba do pracy na innym porcie (np. 8081), ale to rozwiązanie ma dość istotną wadę: nie uzyskamy dostępu do aplikacji korzystając z sieci, która ma otwarte tylko podstawowe porty sieciowe (przykładowo eduroam na uczelniach). Drugi sposób, to przekierowanie ruchu z Apache’a do GitLaba dla wybranej domeny w sposób transparentny dla użytkownika. Tym się zajmiemy w dalszej części tego wpisu.

Spodziewaliśmy się GitLaba, a zastaliśmy stronę serwowaną przez Apache.
Spodziewaliśmy się GitLaba, a zastaliśmy stronę serwowaną przez Apache.

Przekierowanie

Przekierowanie żądań z Apache skonfigurujemy wykorzystując host wirtualny i subdomenę. Najpierw wyłączymy serwer nginx wbudowany w GitLaba oraz skonfigurujemy usługę gitlab-workhorse do obsługi żądań na wybranym przez nas porcie TCP – na przykład 8181. W tym celu musimy wyedytować plik /etc/gitlab/gitlab.rb, zmieniając w nim następujące linijki:

Następnie przeładowujemy konfigurację GitLaba, wydając komendę:

W tym momencie skonfigurowaliśmy backend GitLaba do słuchania żądań na porcie 8181. Ale zanim będziemy mogli z niego skorzystać musimy skonfigurować wirtualny host na serwerze Apache i skonfigurować na nim serwer proxy.

Utwórzmy więc nowy plik w lokalizacji: /etc/apache2/sites-available/001-gitlab.conf

I wypełniamy go w następujący sposób:

Jak można zauważyć, skonfigurowany został tu reverse proxy, zatem zanim będziemy mogli uruchomić tą konfigurację, musimy załączyć kilka modułów do serwera Apache. Skorzystamy z konsolowej aplikacji a2enmod.

Jeśli chodzi o mechanizm reverse proxy, bardzo przypomina on w działaniu zwykły serwer pośredniczący, z tym że jego użycie konfigurowane jest przez administratora serwera, a nie użytkownika. Więcej informacji na ten temat można znaleźć np. na Wikipedii.

Na sam koniec uruchamiamy naszą konfigurację i restartujemy serwer Apache 2.

W tym momencie mamy gotową konfigurację, którą założyliśmy sobie na początku tego wpisu. Możemy wejść na skonfigurowany adres i powinniśmy ujrzeć naszego GitLaba. Przy pierwszym uruchomieniu będziemy musieli nadać hasło dla konta root.

Przy pierwszym uruchomieniu musimy nadać hasło dla użytkownika root.
Przy pierwszym uruchomieniu musimy nadać hasło dla użytkownika root.
W końcu upragniony widok. GitLab dostępny na standardowym porcie! :-)
W końcu upragniony widok. GitLab dostępny na standardowym porcie! 🙂

Podsumowanie

Uruchamianie kilku usług na jednym serwerze wiąże się z korzystaniem momentami ciekawych konfiguracji. W naszym przypadku przy okazji instalacji GitLaba poznaliśmy bardzo prosty przykład konfiguracji reverse proxy na Apache2.

Źródła

Pomodoro Timer 1.1

Tydzień temu wydałem nową wersję mojej aplikacji Pomodoro Timer. Jako cel postawiłem sobie rozszerzyć funkcjonalność aplikacji o kilka przydatnych funkcjonalności, które pokrótce opiszę w tym wpisie.

Zliczanie czasu przerwy

W pierwotnej wersji programu nie dodałem licznika czasu wymuszonej pauzy. W poprzednim wpisie opisywałem, że mój porządek pracy zakłada, że jeśli czas wymuszonej przerwy będzie większy od standardowej przerwy w cyklu Pomodoro, to będę takową pomijał. Ten licznik rozwiązuje ten problem.Licznik pauzy

Prosta statystyka cykli

Nic nadzwyczajnego, zwykły licznik przebytych interwałów. Natomiast obecna implementacja tego bardzo mi się nie podoba i planuję rozbudowę o dokładniejsze statystyki (globalne, miesięczne, itp), gdyż aktualnie są to dane z bieżącej sesji programu.Prosta statystyka cykli Pomodoro

Bajer – pasek postępu w pasku zadań

Wiem, że cykl Pomodoro zakłada skupienie nad zadaniem, ale od czasu do czasu brakowało mi informacji o tym, ile czasu mi zostało do końca cyklu. W efekcie zbyt często Alt-Tabowałem się do programu, żeby zobaczyć pozostały czas. Implementacja tego prostego ficzera rozwiązała ten problem.Pasek postępu w Taskbarze

Download i podsumowanie

W tym wpisie chciałem, oprócz poinformowania o nowej wersji programu, rozszerzyć informację o ideę, która spowodowała utworzenie ww. funkcjonalności. Tworzenie fajniej aplikacji to proces, za którym idą pewne implikacje (np. za często Alt-Tabuję ⇒ Zrobię pasek postępu), co, mam nadzieję, uwidoczniłem opisując wprowadzone przeze mnie zmiany. Poniżej zamieszczam linki do pobrania aplikacji. Pozdrawiam serdecznie!

Mirrory:

 

Nowa aplikacja: Pomodoro Timer

Czasami trudno jest zapanować nad czasem i rzeczami, które powinniśmy zrobić danego dnia. Nie pomagają także wszechobecne rozpraszacze, takie jak serwisy społecznościowe, czy komunikatory. Przez to trudno jest utrzymać jakiś rygor czasu i, w efekcie, zrobić wszystko, co sobie zaplanowaliśmy na dany dzień. Z pomocą przychodzi Technika Pomodoro oraz moja nowa prosta aplikacja Pomodoro Timer.

Krótko o Technice Pomodoro

Technika Pomodoro polega na dzieleniu czasu na krótkie interwały (zwyczajowo po 25 minut), po których następują krótsze lub dłuższe przerwy – podobno pomaga to w utrzymaniu koncentracji. Przed rozpoczęciem cyklu określamy, czym się chcemy w danej chwili zająć. W trakcie takiego cyklu skupiamy się na tym konkretnym zadaniu i, w miarę możliwości (a najlepiej wcale), nie zajmujemy się niczym innym. Kiedy cykl się skończy, odznaczamy go sobie gdzieś na boku i robimy krótką przerwę. Po czterech cyklach robimy sobie dłuższą przerwę w pracy. To tak w skrócie. Ja postanowiłem lekko dostosować tę technikę do swoich potrzeb. Przede wszystkim, kiedy jakieś zadanie pochłonie mnie bardziej, pomijam sobie krótką przerwę. A po drugie, kiedy suma czasu wymuszonych przerw podczas interwału (np. przez telefon, lub rozmowę z domownikiem) przekroczy długość krótkiej przerwy, to także nie odbywam przerwy po cyklu (niezależnie czy długa, czy krótka). Dla jasności dodam tylko, że jedno zadanie nie musi być tożsame z jednym cyklem, w końcu są problemy prostsze i bardziej złożone.

Opis aplikacji, technologii, etc.

I to wszystko zainspirowało mnie do napisania prostej aplikacji – timera, do kontrolowania czasu interwałów. Z racji, że chciałem się podszkolić nieco z języka C#, to w nim powstał Pomodoro Timer. Do utworzenia GUI postanowiłem skorzystać z technologii WPF. Powody takiej decyzji były proste – WPF bardzo dobrze (Out Of The Box) współpracuje z ekranami HiDPI oraz wykorzystuje do opisu interfejsu język XAML. Otwiera mi to drogę do względnie prostej konwersji mojej aplikacji do Aplikacji Uniwersalnej Windowsa 10. Rodzi się pytanie, dlaczego od razu nie zdecydowałem się na stworzenie Universal App? Kompatybilność wsteczna – chcę, aby mój program nie był ograniczony tylko do najnowszej wersji systemu Windows.

Sama aplikacja prezentuje się następująco:

Okno główne programuJak widać, interfejs programu jest na tyle prosty, że opanowanie jego obsługi to kwestia może 10 kliknięć. Najważniejszą funkcją programu jest odliczanie czasu oraz poinformowanie użytkownika o tym, że czas minął – aktualnie jest to po prostu dźwięk.

Aplikację udostępniłem na licencji GNU GPL, więc każdy może ją legalnie pobrać (wraz z kodem źródłowym). Repozytorium z kodem źródłowym dostępne jest na serwisie GitHub. Umieściłem tam też wersję binarną pierwszej (1.0.4) pełnej wersji programu. Odpowiednie odnośniki znajdują się na końcu tego wpisu.

Plany rozwoju

Przede wszystkim, na początku chcę rozbudować mój program o kilka funkcjonalności:

  • Opcje pozwalające zmienić długość poszczególnych interwałów
  • Licznik odbytych cykli
  • Timer mierzący czas wymuszonej przerwy (poprzez kliknięcie przycisku Stop)

To są rzeczy, którymi najprawdopodobniej zajmę się w pierwszej kolejności. Inną, która przychodzi mi aktualnie do głowy to tłumaczenia programu na inne języki – bardziej z chęci nauczenia się tworzenia tłumaczeń w aplikacjach, niźli rzeczywistej potrzeby. Tym jednak planuję się zająć nieco później, kiedy już moja wiedza na temat C# będzie nieco bardziej zaawansowana.

I to by było na tyle. Zachęcam do pobrania aplikacji, pobawienia się nią i przekazania feedbacku na jej temat, np. w komentarzach do tego wpisu oraz sekcji Issues na GitHubie. Jeśli potrafisz także nieco zakodować, to możesz śmiało wysłać pull requesta ze swoją zmianą.

Linki

Źródła

  1. https://en.wikipedia.org/wiki/Pomodoro_Technique
  2. Francesco Cirillo, „Pomodoro Technique”

Hello world!

Witajcie!

Pierwszym programem, jakim zazwyczaj piszemy poznając nowy język programowania jest prosta aplikacja wypisująca na ekran tekst „Hello World!”. Tak i tutaj tworząc swojego bloga pierwszy wpis zatytułowałem przywitaniem świata.

W przeszłości tworzyłem wielokrotnie mnóstwo zapowiedzi, z których zazwyczaj niewiele wychodziło, ale na tym polega życie i rozwój osobisty, aby wyciągać wnioski z błędów swoich i cudzych, żeby ich więcej nie popełniać. Oczywiście wymaga to ogromnej pracy, ale zgodnie z filozofią Slight Edge* trzeba popełniać małe kroki, aby w efekcie osiągnąć coś więcej.

Nie chcąc przedłużać tego mało treściwego wpisu, słowo na temat zawartości. Od wielu lat moją pasją jest informatyka, łatwo więc się domyślić, że to ona zajmie tutaj główne miejsce na blogu. Przede wszystkim skupię się na kilku jej dziedzinach, ale jakich… to się okaże w kolejnych wpisach :-).

Jeśli dotarłeś/aś aż tutaj w tym wpisie, to szacunek, ale w końcu sam przecież czytam wstępy wszystkich książek, po które sięgam. Pozdrawiam serdecznie!

* Więcej w książce Slight Edge Jeffa Olsona