23:55
6/9/2017

Ruszył rok szkolny, więc my dziś o szkole, bo popularny dostawca systemów dla szkół niechcący udostępnił pliki z danymi dotyczącymi m.in. płac nauczycieli niektórych szkół. Interesujące jest to, że “wyciek” wyszedł na jaw dzięki publicznie dostępnej instrukcji obsługi dla klientów. O tym, że na zrzutach ekranu można wypatrzeć różne smaczki pisaliśmy już nie raz. I to jest kolejna historia tego typu.

Vulcan to firma bardzo znana na rynku narzędzi dla jednostek oświatowych. Oferuje e-dzienniki, programy do naliczania płac, obsługi kadr i prowadzenia inwentaryzacji. Jak zapewne się domyślacie, do systemów obsługiwanych przez Vulcan trafia mnóstwo danych osobowych zarówno uczniów, jak i rodziców oraz nauczycieli. Firma Vulcan jest świadoma znaczenia tych danych i wiemy, że bezpieczeństwo traktuje poważnie. Ale nawet firmom świadomym zagrożeń i minimalizującym ryzyko ich występowanie może zdarzyć się coś… bardzo niespodziewanego.

Hmmm… a co to za katalog?

Jeden z naszych Czytelników przeglądał sobie pliki w internetowej bazie wiedzy firmy Vulcan i trafił na plik PDF z instrukcją udostępniania danych na potrzeby wykonania usługi wdrożeniowej. Dokument na stronie już podmieniono, ale wersja znaleziona przez naszego Czytelnika zawierała taki screenshot:

Czy te katalogi naprawdę istnieją? Nasz Czytelnik postanowił to sprawdzić i wpisał w przeglądarkę adres ftp://ftpdane.vulcan.pl/NAZWA%FOLDERU/. I stało się! Uzyskał dostęp do spakowanych plików *.bkp, do których dostęp nie był chroniony żadnymi hasłami. A pliki te( (czyli kopie baz) zawierały informacje o osobach zatrudnionych w szkołach…

…a także o wynagrodzeniach.

Uzyskanie dostępu nie wymagało przełamywania żadnych zabezpieczeń, więc możemy mówić o tzw. “głębokim ukryciu“. Uspokójmy jednak od razu wszystkich klientów oprogramowania firmy Vulcan — w dostępnym katalogu znajdowały się pliki dotyczące tylko kilku szkół, a nie wszystkich obsługiwanych przez Vulcan. I to w dodatku tych, które same te pliki Vulcanowi przekazały…

Vulcan: Błąd przy pracach administracyjnych

Zwróciliśmy się do firmy Vulcan ze zgłoszeniem problemu i następującymi pytaniami.

1. Jakie dane wyciekły w opisany powyżej sposób?
2. Czy instytucje, których dane wyciekły, zostaną o tym powiadomione?
3. Czy firma Vulcan podejmie jakieś kroki, aby zapobiec podobnym wypadkom w przyszłości?

Reakcja była natychmiastowa. Najpierw nieoficjalnie dowiedzieliśmy się, że ktoś przy wdrożeniu niepotrzebnie wrzucił pliki do katalogu niezabezpieczonego, choć sam katalog miał być zabezpieczony. Doszło więc nie tyle do “wycieku z Vulcanu” co raczej do przeoczenia.

Później otrzymaliśmy obszerniejszą odpowiedź, której autorem był Jan Koziarski, Dyrektor Pionu Marketingu w Vulcanie:

Na wstępie bardzo dziękujemy za przekazanie informacji o problemie bezpieczeństwa – niezwłocznie podjęliśmy działania w celu analizy sytuacji i wyeliminowania problemu. Nasz serwer FTP pozwala na zapisywanie plików bez prawa do ich odczytywania. Incydentalnie, w wyniku prac administracyjnych, powstała możliwość utworzenia nowego katalogu z możliwością odczytywania zawartości.

Odpowiadając na pierwsze Pana pytanie incydent dotyczył danych związanych z naliczaniem wynagrodzeń kilkunastu naszych Klientów, a przekazanych nam w celach serwisowych.

Odpowiadając na Pana drugie pytanie – tak, oczywiście. Przekazana przez Pana informacja, zgodnie z naszą polityką bezpieczeństwa jest incydentem bezpieczeństwa, co m.in. oznacza, że niezwłocznie informujemy wszystkich administratorów danych naszych Klientów o takim fakcie oraz przekazujemy im wszystkie posiadane przez nas informacje o zdarzeniu. Do wszystkich Klientów, których zidentyfikowana luka mogła dotyczyć wysłaliśmy w dniu dzisiejszym stosowne informacje. Placówki te będą także na bieżąco informowane o kolejnych naszych ustaleniach w sprawie.

Odpowiadając na Pana trzecie pytanie – tak, oczywiście. Każdy incydent bezpieczeństwa kończy się wyciągnięciem wniosków oraz podjęciem działań zmierzających do wyeliminowania możliwości lub zmniejszenia prawdopodobieństwa wystąpienia analogicznego problemu w przyszłości. Ze względu na charakter problemu, który w tym przypadku się pojawił, z dużym prawdopodobieństwem (nawet na tym etapie jego wyjaśniania) można się spodziewać, iż docelowym rozwiązaniem będzie zmiana modelu przekazywania kopii baz danych aplikacji desktopowych do serwisu. Aktualnie konfiguracja serwera została tak zmodyfikowana aby nie powtórzyć tej sytuacji oraz zostały wprowadzone zmiany w procedurze przekazywania pików przez Klientów. Oczywiście to rozwiązanie doraźne będzie funkcjonować do czasu opracowania i wdrożenia nowego modelu, o którym wspomniano powyżej.

Dodamy jeszcze, że podmieniono plik PDF z instrukcją, a więc tę “lukę” również załatano.

Ochrona danych w szkole i na uczelni – niełatwy temat

Środowisko edukacyjne jest bardzo trudne, jeśli chodzi o ochronę danych. W szkołach dochodzi do przetwarzania mnóstwa danych osobowych (czasem wrażliwych), a dostęp do nich musi mieć sporo osób. Wiele rzeczy w szkole ma być zrobione “na wczoraj”, a nowe rozporządzenia wymagają ciągłych zmian i dostosowywania systemów. W takich warunkach nietrudno o błąd. W dodatku, coraz więcej szkół powierza przetwarzanie danych firmom oferującym usługi chmurowe i to przenosi część odpowiedzialności na te firmy. Zresztą to wrzucanie danych do chmury często jest “na własną rękę”, bo bywa że nauczyciele pod presją dyrekcji lub władz gminy “informatyzują” swoje działania korzystając z powszechnych usług (jak Google Drive albo — co gorsze — skrzynka e-mail, do której login i hasło zna 30 osób).

P.S. Poza danymi osobowymi w instytucjach oświaty mogą być inne cenne dane, np. arkusze egzaminacyjne. Zawsze znajdzie się ktoś, kto zechce przetestować ich podatności.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

59 komentarzy

Dodaj komentarz
  1. Wiele firm działa, ze każe przesłać dane w sposób nie zabezpieczony. Nie maja ogóle pomysłu jak zrobić to bezpiecznie jak tylko e mail lub zwykły ftp

    • A znasz równie łatwy i prosty sposób, który mógłbyś polecić ludziom kompletnie nietechnicznym, którzy potrafią co najwyżej otworzyć wskazany katalog i kliknąć na pliku PPM->Wyślij do->Adresat poczty?
      Wszystkie rozwiązania transmisji danych, z którymi się zetknąłem jest napisanych dla ludzi mocno obeznanych z IT.
      Serio pytam, czy istnieją takie rozwiązania, ale skierowane do zwykłych “Kowalskich”, z prostotą na poziomie PPM->Wyślij do->Adresat poczty?

    • @Kenjrio
      Jeśli chodzi o pocztę, to może PGP? Ma swoje minusy, ale zawsze to jakaś ochrona. Do tego użycie gotowego klucza nie jest skomplikowane. Być może potrzebny był by tylko ktoś bardziej techniczny do konfiguracji (wygenerowanie klucza i konfiguracja serwera/oprogramowania pocztowego).

    • Istnieją. Wystarczy napisać/użyć dostępnego oprogramowania które po uruchomieniu poprosi o login i hasło, zestawi bezpieczny tunel ssh/scp i będzie można tam wkleić pliki. Proste i bez kombinacji.

    • Może na początek osoby nietechniczne zaczęły by korzystać z protonmaila lub tutanoty?

    • Expirebox z zaszyfrowaną paczką?

    • @Kenjiro
      niech i zostanie ten http://ftp... +zip z hasłem… Myślę, że nawet “Pani Jadzia z sekretariatu” da rade.
      Firma zawsze może udostępnić jakiegoś skonfigurowanego klienta ftp (np wersja portable), który łączyłby się po ftps – oczywiście jakiś zip zabezpieczony hasłem. Choć to wydaje mi się bardziej skomplikowane. No! Ale od czego mamy instrukcje ;)

    • A co jest zlego w udostepnianiu danych poprzez FTP z prawem tylko do zapisu?
      Sam dla jednej firmy, ktora robi wydruki wielkoformatowe projektow glownie budowlanych, uruchomilem (S)FTP na ProFTPd, gdzie klienci moga tylko zapisywac. Do tego oczywiscie blokada wrzucania plikow z potencjalnie zlosliwymi rozszerzeniami, oraz blokada uruchmiania plikow/skryptow. Calosc mozna jeszcze skanowac w locie ClamAVem (sredni pomysl), albo trzymac zawartosc w jakims zdalnym katalogu i skanowac np. Kasperskim. Do tego blokada tzw. bad IPs i/lub blokada IP spoza PL. To jest najlatwiejsza metoda i latwa do wytlumaczenia kazdemu.

    • Najprostsze rozwiązanie: stronka webowa z https a na niej przycisk “wyślij plik”. Nawet małpa sobie poradzi.

      Dla bardziej zaawansowanych: prosta instrukcja jak zrobić zipa z hasłem i wysłać.

      Dla wybrednych: instrukcja instalacji i użycia WinSCP plus konto z silnym hasłem dla każdego klienta.

    • Malgond:
      Szczegolnie jak masz 20 plikow po 50MB kazdy. Do takich akcji jest FTP.

    • Wujek Pawel:
      a co za problem zrobić na stronie formularz do obsługi wielu plików?
      chociaż oczywiście najlepszy byłby exec, który by to spakował przed wysłaniem

    • @Wujek Pawel

      > blokada IP spoza PL
      Dlaczego chcesz blokowac uzytkownikow laczacych sie przez VPN?

    • Michal:
      VPN nada im adres w sieci lokalnej, a te w domyśle powinny być dozwolone

    • @Zakius.
      Nada im adres w sieci lokalnej serwera VPN. Widzalni na zewnatrz (przez serwer FTP) beda juz pod adresem serwera VPN.

      @Michal,
      Zakladamy, ze pliki na serwer wrzucala bedzie osoba, ktora w kwestiach IT, a tym bardziej bezpieczenstwa jest laikiem, wiec o jakim VPN my tu rozmawiamy. W przypadku firmy, ktory opisalem sa to glownie projektanci, architekci, geodeci. Nie oczekuj od tej grupy ludzi, ze beda uzywali np TORa do wrzucenia swojej dokumentacji na serwer.

    • @zakius
      Chyba, ze “siec lokalna” oznacza np. kwatere glowna w USA…

  2. “A znasz równie łatwy i prosty sposób, który mógłbyś polecić ludziom kompletnie nietechnicznym, którzy potrafią co najwyżej otworzyć wskazany katalog i kliknąć na pliku PPM->Wyślij do->Adresat poczty?
    Wszystkie rozwiązania transmisji danych, z którymi się zetknąłem jest napisanych dla ludzi mocno obeznanych z IT.
    Serio pytam, czy istnieją takie rozwiązania, ale skierowane do zwykłych “Kowalskich”, z prostotą na poziomie PPM->Wyślij do->Adresat poczty?”

    Czy tylko ja uważam, że takie “aplikacje” powinny mieć wbudowane mechanizmy do przesyłania takich danych? Czy to taki wielki problem wbudować w program takie narzędzie do wysyłania plików np. z kopią bazy? Wtedy “Pani Jadzia” wchodzi tylko do odpowiedniej zakładki i postępuje zgodnie z komunikatami na ekranie… Ludzie przecież to jest oczywiste!

    • Niestety, serwery poczty czesto maja limity wielkosci pojedynczej wiadomosci. Wyobraz sobie klienta, ktory ma projekt budowlany z rysunkami wielkoformatowymi (A0) w kolorze, gdzie czasem pojedynczy PDF potrafi zajmowac 50MB. Wtedy tylko (s)FTP.

    • @Wujek Pawel

      “mechanizmy przesylania danych” to niekoniecznie email :-)

    • @Michal,
      Oczywiscie, ale kazdy inny mechanizm to juz dodatkowa komplikacja, a ma byc prosto bo tego typu rozwiazan czesto uzywaja laicy.

    • @Wujek Pawel
      To nie developerowi ma byc latwo, tylko uzytkownikowi :-)

      Zwykli ludzie na codzien nie uzywaja programow do obslugi FTP, wiec to znowu nie jest dla nich jakies ulatwienie.
      Taki Dropbox czy GoogleDrive umozliwiaja uzytkownikowi (uzywajacemu interfejsu webowego) na wrzucenie wielu plikow lub folderow jednoczesnie, wiec nie widze problemu w budowaniu podobnych rozwiazan.

    • @Michal
      Tak, będę jeszcze rekrutację na soft developera robił, żeby mi po pół roku napisał panel do wrzucania plików za 5k PLN.

    • @Wujek Pawel:

      OK, jezeli chcesz sobie ulatwic zycie i umozliwic Twoim klientom zdalne wrzucanie plikow to byc moze FTP jest OK. Myslalem, ze rozmawiamy o jakims komercyjnym produkcie :-)

      PS. Pol roku pracy i 5k? Gdzie Ty ludzi szukasz? W Kambodzy? xD

    • @Michal,
      Ty chyba nigdy programisty nie rekrutowales. Zalozmy nawet, ze mam juz developera, ktory mi to napisze i calosc nie bedzie potrzebowala do dzialania SQL/Ajax/PHP/Zend/Pythona/Perla. Ide o zaklad, ze przy pierwszej wiekszej aktualizacji Nginxa/Apache czegokolwiek innego potrzebnego do dzialania tej aplikacji, ta przestanie dzialac.

    • @Michal,
      Zreszta, przedstaw mi tu swoje dzialajace rozwiazanie problemu. Bo ja Ci jestem w stanie wkleic konfig ProFTPD + firewalla. Calosc moze dzialac na kompie z Pentium G i 512MB RAMu. Pamietaj, ze piszemy o jednorazowej wrzutce 100 plikow po 50MB kazdy.

    • Spakuj 7zipem z AESem i hasłem.Urzędnicy od Macierewicza mogą straszyć “ruskimi” ale prawda jest taka,że to jest bezpieczne i łopatologicznie proste.Klikasz prawym przyciskiem myszy pakowanie z opcjami hasło ustawić i tyle.Pani Jadzia pod windozą powinna sobie z tym dać radę.A “za duże pliki” ? No to archiwizować po kolei !

    • @Wujek Pawel

      nie wiem po co chcesz rekrutować, przecież w Internecie masz tysiące skryptów PHP do ładowania plików, np. owncloud, Seafile, itd., nie musisz tworzyć komuś konta, wystarczy że udostępnisz skrytkę do wsyłania plików w postaci linków… i tyle…

  3. Jeśli problemem jest proszenie ludzi nietechnicznych o podesłanie danych ludziom technicznym w bezpieczny sposób – to ludzie techniczni odpowiedzialni są za dostarczenie narzędzi ludziom nietechnicznym, by ci mogli zrobić to w sposób bezpieczny. Postawienie prostego panelu do podsyłania plików zajęłoby zapewne dzień – dwa. Niezbyt wygórowana cena bezpieczeństwa danych.

    • Robienie tego przy pomocy PHP to zly pomysl. Najlatwiej zrobic to na FTP co opisalem wyzej.

    • @Wujek Pawel

      “server side” to nie tylko PHP :-)

      Od kiedy uzywanie programu do FTP to najprostsze (dla uzytkownika) rozwiazanie?

    • @Michal,
      Zaprezentuj mi wiec rozwiazanie oparte o web, rownie wydajne i latwe w implementacji co serwer FTP. Przy czym mowiac wydajne, mam na mysli, ze serwer nie bedzie musial miec 64GB RAM i dualnego Xeona zeby przerobic 100 plikow po 50MB za jednym razem, bedzie je w stanie przeskanowac pod katem malware itp. Mowiac latwe w implementacji, mam na mysli, ze nie bede musial sleczec nad kodem dwa dni.

      Po co utrudniac sobie zycie?

    • @Wujek Owncloud/Nexcloud? Oczywiście wymagania będą większe niż przy FTP, ale bez przesady – nawet jeśli ściągniesz ze strychu 10-letniego PCta i dobrze go skonfigurujesz, to spokojnie uciągnie 100 równoległych połączeń, a komfort korzystania i możliwości bez porównania.

  4. Witam.
    Wystarczy aplikacja webowa pod https z logowaniem indywidualnym oparta na tzw. formularzach. Tak działają telekomy od wielu, wielu lat i się to sprawdza. Zero techniki dla użytkownika końcowego bo jest to zbliżone do obsługi poczty przez WEB. Wszystko bezpieczne i proste.

  5. Ogólnie prędzej nie umieli wdrożyć cloudflare i uczniowie ddos owali dziennik przez prawie miesiąc. Po telefonach i mailach codziennych wow wdrożyli. Co do wdrażania rozwiązań to wszystko super ale powiedzcie jak wdrożyć pgp jak większość nie umie ustawić ikonki mój komputer na pulpicie.

  6. Co do ludzi technicznych i nauczycieli, pozwólcie że opowiem co widziałem na zebraniu dla rodziców rok temu.
    – Pani wychowawczyni chciała zaprezentować e-dziennik, włączyła “klasowego” laptopa i po wejściu na stronę przeglądarka sama podpowiedziała login i zagwiazdkowane hasło innego nauczyciela.
    – usunęła je, kliknęła na pole user, pojawiły się chyba 3 loginy i po prostu wybrała swój login ….

    kurcze, jeżeli wszyscy pracują na jednym profilu, mają hasła zapisane w przeglądarce a komputer jest praktycznie publicznie dostepny bo leży w sali to jest proszenie się o kłopoty.

    • nie oczekuje wiedzy tajemnej, tylko trochę świadomośći i zdrowego rozsądku. Ciekawe czy papierowy dziennik też zostawiali na biurku bez żadnego zabezpieczenia ?

  7. Swego czasu w firmie, w której pracowałem, obsługiwaliśmy kilka szkół. W każdej z nich, gdzie był soft Vulcan-a, szkoły decydowały się na wdrożenie ich dziennika elektronicznego (bo był za darmo, jako część zestawu). Coś potwornego. Jeden wielki bloatware. Żeby działał, wymagał Silverlighta, wszelkich frameworków .Net i IE. A chodziło to tak, że szkoda gadać. Na starszych komputerach (fakt, typowa maszyna do pisania), jak odpaliły dziennik na pierwszej lekcji, to “już” na drugiej mogły z niego korzystać.

  8. Jakie na wczoraj? W szkole mojej córki system jest wdrożony od 2 lat i nikt niczego nie wpisuje, ocen, planów zajęć, prac domowych etc. System jest używany jedynie jako substytut e-maila do komunikacji z rodzicami.

    • Może mają też zwykły dziennik i nie chce im się przepisywać? Dzienniki elektroniczne mają sens tylko wtedy, kiedy nie ma w ogóle papierowego.

  9. Widać że nauczycielom, niektórym, źle nie jest. Są tacy, co po 53k zgarniają :-)

    • To jest pensja na rok.

  10. “Vulcan jest świadoma znaczenia tych danych i wiemy, że bezpieczeństwo traktuje poważnie. ”

    A “wiemy” to na podstawie takiej amatorszczyzny jak opisana, czy czegos wiecej?

  11. Vulcan’t tak dba o bezpieczeństwo, że na stronie edziennika dla uczniów jest javascript w samym źródle, nie w osobnym pliku, kompletnie nieminifikowany, z komentarzami i ze wszystkim. Nie przyglądałem się, w jaki sposób i czy w ogóle możnaby te informacje wykorzystać ale można się z tego javascripta bez większego problemu dowiedzieć np. jak są tworzone requesty o informacje w planach dla nauczycieli i inne rzeczy których ani uczeń ani rodzic widzieć raczej nie powinien.

    • Co ma niezminifikowany JS z komentarzami do bezpieczeństwa? To tylko kwestia optymalizacji. A sprawdzić jak są tworzone requesty można za pomocą byle burpa, nie trzeba do tego patrzeć w źródło.

    • Minifikowany Javascript w ZADEN sposob nie poprawia bezpieczenstwa. Z minifikowanego kodu tak samo mozna sie dowiedziec jak sa “tworzone requesty” – taka wiedza, przy dobrze zaprojektowanym systemie, jest jednak bezuzyteczna.

      Niezminifikowany kod swiadczy raczej o niechlujstwie.

  12. Są proste i otwarte rozwiązania chmurowe, które można uruchomić na własnych serwerach. Firmy nie stać na bardziej wydajny serwer? To co to za biznes prowadzony na kolanie? Sprzedać samochód i kupić tańszy.

    • Po co firma ma wydawac kupe kasy na opensourcowa chmure oraz na admina, ktory bedzie o to dbal 24h na dobe? Zwykly VPS z autmatycznymi updetami 1 CPU, 512MB RAMu i na tym ProFTPd wystarcza w zupelnosci.

    • @Wujek Paweł

      o to też trzeba dbać – równie dobrze stawiasz na tym OwnCloud-a i puszczasz ruch po https – prostsze i bezpieczniejsze (certyfikat w wersji “skąpo” robisz na let’s encrypt). Admina jakiegoś i tak firma tej skali mieć musi więc taki jeden serwerek to dla niego pikuś.

  13. Skąd wydawnictwo miało info o zarobkach w szkołach? Pracownicy placówek już TAKIE rzeczy umieszczają w ankietach?!

    • pewnie była to baza programu kadry i płace :D

    • Tak, bo nie myślą.

  14. Tak z innej beczki…
    Mówicie, że ochrona danych osobowych w szkołach to niełatwy temat? Spróbujcie ogarnąć to w jakimś urzędzie miasta/gminy …
    Przykład:
    http://bip.um.wroc.pl/artykuly/516/rejestr-zbiorow-danych-osobowych-gminy-wroclaw

    80% z tego wykazu występuje w każdej gminie, łącznie z takimi gdzie jest 20 “urzędników”.
    A założę się, że na tym wykazie jakby poszukać to jeszcze trochę brakuje ….

  15. Pamiętam jeden program VULCAN do listy płac nauczycieli (jeszcze pod MS-DOS). Program był nazwijmy to “chroniony” hasłem. Jak ktoś nie znał hasła, wystarczyło tylko usunąć jeden plik konfiguracyjny a wtedy po ponownym uruchomieniu program pytał 2x o nowe hasło i pozwalał na normalną pracę!!! Jeśli zamiast wykasować przechowaliśmy plik konfiguracyjny gdzieś poza katalogiem programu to po przywróceniu do pierwotnej lokalizacji znów wracało stare hasło i kadrowa mogła się logować nie podejrzewając, że ktoś w międzsyczasie coś majstrował. Oczywiście pliki bazy danych nie były szyfrowane bo po co? :)

    • Z tego co ja pamiętam to program płacowy Vulcan miał od 1995 roku. Ja na ich programach pracuję od połowy 1998. I od wtedy sama baza nie była szyfrowana, ale imie i nazwisko tak.
      Bez problemu można było odczytać pesel i adres.

    • W tym programie co ja znam imiona i nazwiska też nie były szyfrowane ale były w oddzielnych plikach tabel (tabela główna zawierała klucze obce z numerami ID do imion i nazwisk). Czyli twórcom znane było pojęcie normalizacji bazy danych. :)

  16. Czasem coś wysyłałem na ftp Vulcana. Kiedys mozna było zobaczyć kto i co wysyłał. Można było i pobrać. ale to dawne czasy. Ostatnio Nie było nawet widać kto wysyłał. Ciekawe z kiedy to znalezisko jest

  17. Czytam wypowiedzi osób, które opisują jak należy to zrobić prawidłowo i lepiej i zastanawiam się, czy poza pisaniem tych komentarzy miały kiedykolwiek do czynienia z praktycznym wykorzystaniem wiedzy którą prezentują?
    Ktoś pisze, że najprostsze rozwiązanie to stronka webowa i na niej “wyślij plik”. Inny na zwróconą uwagę, że do wysłania 20 plików po 50MB każdy takie rozwiązanie się nie nada odpowiada, że to przecież nie problem zrobić na stronie formularz do obsługi wielu plików.
    No więc pytanie: robiliście kiedyś taką “stronkę”? Przez którą ktoś miałby ładować gigabajtowe dane? Czy może ograniczyliście się do robienia wrzucaczy obrazków bez problemu ładujących wiele zdjęć? 20 plików po 50 MB to gigabajt danych. Liczebnikowo: 1GB. Przy transferze z prędkością 20Mb/s ich “załadowanie” przez stronę będzie trwało około 7 minut – i to zakładając, że cały czas taki transfer da się utrzymać. Jaki jest prawdopodobieństwo, że w trakcie tych 7 minut nastąpi zerwanie połączenia? Spróbujcie załadować 1GB na serwer przez “prostą stronkę” – a potem krytykujcie innych.
    O czymś takim, jak brak pewności, czy plik został w całości załadowany, czy może coś się “urwało” nawet nie wspominając. Tak, właśnie po to wymyślono różne protokoły. File Transfer Protocol zapewniający np. wznawianie przesyłu po zerwaniu połączenia. HyperTEXT Transfer Protocol do przesyłu “tekstu”, a dopiero później “przy okazji” wykorzystywany do przesyłu elementów stron. Wysyłanie dużych plików przez http/https to jak wożenie cegieł w betoniarce. Pewnie że się da, tylko jaki ma to sens?

    Kolejna osoba wpadła na genialny pomysł, że jak te pliki są takie duże, to trzeba je … skompresować. Nie no, geniusz. Nikt by nie wpadł na to, że można. Choć raczej większość wie, że tak się robi. I że te 20x50MB to mogą być właśnie spakowane dane, podzielone na kawałki (popularny sposób pakowania). Ale żeby nie proponować takich “genialnych” rozwiązań trzeba mieć do czynienia z czymś więcej, niż kopie danych budżetu domowego. Z czymś, gdzie kopia wycinka danych to gigabajty danych. A skopmresowane kopie baz przenosi się na dyskach, bo na żadnym nośniku typu DVD czy Blu-ray się nie zmieści.

    Kwestia fuckupu firmy jest bezdyskusyjna. Ale z drugiej strony: jak coś komentujecie, to weźcie też pod uwagę że skoro Wasze rozwiązanie jest tak genialnie proste, to jego nie stosowanie nie wynika z faktu, że poza Wami wszyscy inni są tępymi matołami skoro nie potrafią zrobić czegoś z czym “nawet małpa sobie poradzi”. Pomyślcie, czy macie wystarczającą PRAKTYKĘ, aby wyskakiwać z takimi pomysłami.

    • Jest mnóstwo gotowych skryptów potrafiących ładować wiele plików jeden po drugim w wielu żądaniach z ładnym postępem wysyłania i obsługą D&D. Masz wtedy nie tylko lepsze UX ale też rzeczywisty model uprawnień zamiast protezy z blokadą odczytu dla plików wysłanych przez FTP.
      Z całym szacunkiem dla praktyki, ale warto czasem opuścić swoją strefę komfortu i sprawdzić co też wymyślili w ciągu ostatnich 10 lat…

    • Ej, dekadę temu miałem upload dużych plików oparty o skrypt CGI – działało. Można było wrzucić nawet film i obserwować pasek postępu. Dziś są o wiele ciekawsze narzędzia. Więc da się.

    • jeżeli chodzi o wznawianie to obecne skrypty już to potrafią…
      nawet Youtube potrafi wznowić film przerwany…
      wetransfer nawet wznawia pliki

Odpowiadasz na komentarz Piotr

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: