Mózg to fascynujące ustrojstwo. Czasami zastanawiam się, czy to ja posiadam mózg, czy mój mózg posiada mnie. Na przykład lubi wybrać sobie temat, nad którym postanowi sobie pracować, kompletnie ignorując przy tym fakt, że pora bardziej odpowiednia do snu, niż do myślenia. Mogę albo usiłować spać (czyli wiercić się przez najbliższą godzinę), albo temat pokonać. Przy okazji temat jest odrobinę związany z poprzednią zagadką, więc będę miał mniejsze wyrzuty sumienia związane z chwilowym brakiem kontynuacji tematu.
Widzę, że moja zagadka nie spotkała się z wielkim zainteresowaniem. No ale cóż, to mój blog i mogę na nim pisać o tak nudnych tematach, na jakie mam tylko ochotę. Zwłaszcza, że temat jest ciekawy i ma praktyczne zastosowanie dla ludzi z obu stron barykady.
Kilka pytań naprowadzających:
jakie są oczekiwania odnośnie generowanych identyfikatorów,
czy wymagania są spełnione,
Pytania pomocnicze:
jak długi (w bitach) jest identyfikator,
czy wykonalne jest sprawdzenie wszystkich wartości,
ile wartości trzeba sprawdzić, by trafić w użyty identyfikator,
Założenie jest takie, że przyznawane identyfikatory nie powinny być sekwencyjne, tak by enumeracja obiektów z użyciem bezpośredniego użycia identyfikatora była nieefektywna. Przewiduje się generowanie nie więcej niż jednego identyfikatora na sekundę. Identyfikatory muszą pozostać unikalne przez okres 10 lat.
Okazało się, że w czasie ostatniej ślizgawicy ucierpiała nie tylko moja dup^wduma, ale również taki mój jeden gadżet:
Nie widać tego dokładnie na zdjęciu, ale elektronika jest uszkodzona, w szczególności kość pamięci pokryła się ładną siatką pęknięć.
Nie był to najbardziej pojemny pendrive, szybkością również nie grzeszył. Miał natomiast jedną cechę, którą bardzo lubiłem – po podłączeniu do komputera przedstawiał się jako dysk, a nie jako nośnik wymienny. Co z tego? To, że wówczas można było na nim zrobić partycje (specyfika Windows), jedną zostawić nieszyfrowaną i trzymać na niej niezbędny toolbox, a drugą zaszyfrować w całości TrueCryptem i trzymać na niej notatki z testów.
Zna ktoś może jakieś powszechnie dostępne gadżety, które mają taką samą cechę?
Oryginał tego wpisu dostępny jest pod adresem Buuuu :(
w synchronizowanym folderze utwórz kontener TrueCrypt, zaczekaj aż się zsynchronizuje,
zamontuj kontener, utwórz w nim plik,
odmontuj kontener,
pobierze kontener z Google Drive,
zamontuj pobrany kontener,
...gdzie jest mój plik?!
Właściwie do ostatniego punktu może się nie uda dojść, bo samo zamontowanie kontenera może okazać się niemożliwe (właściwie – otwarcie zamontowanego kontenera).
Załóżmy, że mamy aplikację mobilną, która korzysta z chmury. Aplikacja przechowuje pewne ustawienia/dane specyficzne dla użytkownika, ale nie są to dane, których ujawnienie lub modyfikacja spowodowałyby koniec świata. W takim scenariuszu wymaganie uwierzytelnienia użytkownika może być nadmiarowe, wystarczająca będzie jego identyfikacja. Identyfikacja ta może odbywać się w sposób kompletnie dla użytkownika niezauważalny. Identyfikowana może być instancja aplikacji (konkretna instalacja) lub urządzenie, na którym ta aplikacja jest zainstalowana.
Jeśli ktoś zaoferuje wam wykonanie projektu (najczęściej jakiegoś serwisu) w oparciu o “autorski, profesjonalny CMS”, to uciekajcie tak szybko i tak daleko, jak tylko się da. Może i w jednym przypadku na dziesięć popełnicie błąd. W pozostałych dziewięciu właśnie uniknęliście poważnych kłopotów.
Co do zasady wykorzystanie pewnej dodatkowej “warstwy abstrakcji” ogranicza ryzyko związane z błędami typu SQL Injection. Ogranicza, ale nie eliminuje, bo:
wiedzieć co się użyło (a wybierać rzeczy do użycia też trzeba z głową!),
śledzić informacje na temat użytych elementów,
A co, kiedy ktoś mówi “nie mogę zagwarantować, że po aktualizacji nasz system będzie nadal działał”? Cóż, z tym też można sobie poradzić: Test-driven development.
Oryginał tego wpisu dostępny jest pod adresem SQLi w RoR
