Firefox i mobilny wygląd strony na desktopie

Sprawdzanie, jak strona wygląda na innej przeglądarce, w innym systemie operacyjnym czy nawet w innej rozdzielczości nigdy nie było trywialne. Stało się łatwiejsze dzięki wbudowanej w przeglądarkę Firefox funkcji pozwalającej na podgląd wyglądu strony w określonej rozdzielczości. Na przykład mobilnego wyglądu strony. Fachowa nazwa: responsive design view.

Nie zajmuję się frontendem, więc o sprawie dowiedziałem się przypadkiem. Funkcjonalność chyba nie była specjalnie nagłaśniana, w każdym razie umknęła mojej uwadze. Poza tym w obecnej, wygodnej formie dostępna jest od wersji Firefox 33.

Aby włączyć responsive design view należy wcisnąć ctrl-shift-m. Wyjście z trybu – przycisk X w lewym górnym rogu. Powinniśmy zobaczyć coś w stylu:

Responsive Design View - screenshot

Źródło: https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_View

Dostępne są zdefiniowane ustawienia, ale można też definiować i zapisywać własne rozdzielczości (liczby są edytowalne, następnie enter). Można także rozszerzać okno przy pomocy łapania za krawędzie. Oczywiście nie jest to równoznaczne z przetestowaniem na innym systemie operacyjnym czy w innej przeglądarce, ale jako szybkie sprawdzenie na żywo wyglądu w mniejszej rozdzielczości – idealne i warto wiedzieć, że istnieje, zwłaszcza, gdy użytkownicy zgłaszają, że strona źle wygląda w określonej rozdzielczości. Mi się ta funkcja przeglądarki Firefox przydaje głównie do szybkiego sprawdzenia mobilnego wyglądu strony.

Więcej:

  1. Responsive Design View – pełny opis narzędzia (ang.)
  2. Responsive Web design – ogólnie o responsywnych stronach WWW (ang.)

Własna strona w sieci Tor

Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.

Tor logoŹródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.

Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.

I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.

Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:

############### This section is just for location-hidden services ###

Następnie odhashowujemy/edytujemy dwie linie:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80

Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.

Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].

Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:

cat /var/lib/tor/hidden_service/hostname

Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.

[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.

[2] Więcej w tym wpisie (ANG).

[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.

[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.

[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.

Piwik 2.6.0 i problemy z upgrade

Od jakiegoś czasu korzystam ze statystyk Piwik na większości moich stron ii generalnie jestem zadowolony. Do tej pory aktualizacje wersji były totalnie bezproblemowe (klikalne), ale aktualizacja wersji do 2.6.0 zakończyła się niepowodzeniem.

Od początku wyglądało dziwnie, bo kliknięcie w changelog w mojej instalacji Piwika nie pokazywało listy zmian dla wersji 2.6.0, a w dziale download najnowsza wersja opisana była jako 2.5.0 (choć faktycznie archiwum zawierało 2.6.0).

Automatyczny upgrade zakończył się klęską i pokazywaniem białej strony, postanowiłem zrobić aktualizację ręcznie, jak opisano na stronie. Okazało się, że pobrany plik piwik.zip rozpakowuje się w ślimaczym tempie (ok. 20kB/s). Także na innej, szybszej maszynie, z nowszym Debianem (unstable). Ostatecznie rozpakowałem na tej szybszej, przepakowałem do tar.gz. Przy okazji rozmiar spadł do 8MB w porównaniu z 11MB oryginalnego zip, a rozpakowanie odbyło się w normalnym tempie, czyli parę MB/s. Następnie przeprowadziłem aktualizację ręcznie.

Niewiele to pomogło, bo nadal była biała strona. Ręczne wywołanie pliku piwik.php dało więcej informacji:

PHP Warning:  require(/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php): failed to open stream: No such file or directory in /var/www/piwik/vendor/composer/autoload_real.php on line 58
PHP Fatal error:  require(): Failed opening required '/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php' (include_path='/var/www/piwik/vendor/phpunit/php-text-template:/var/www/piwik/vendor/phpunit/phpunit-mock-objects:/var/www/piwik/vendor/phpunit/php-timer:/var/www/piwik/vendor/phpunit/php-file-iterator:/var/www/piwik/vendor/phpunit/php-code-coverage:/var/www/piwik/vendor/phpunit/phpunit:/var/www/piwik/vendor/symfony/yaml:.:/usr/share/php:/usr/share/pear') in /var/www/piwik/vendor/composer/autoload_real.php on line 58

Szybki debug i znalazł się winny. W pliku /var/www/piwik/vendor/composer/autoload_files.php należy zakomentować odwołania do nieistniejących plików:

#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php',
#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_runs.php'

Po tej operacji wszystko działa poprawnie. HTH

http://pastebin.com/S4Hxjw6B

UPDATE: Szybcy są i czytają Twittera, już (podobno) poprawili wydając 2.6.1. 🙂