Skocz do zawartości

PeterRiley

Użytkownicy
  • Zawartość

    18
  • Rejestracja

  • Ostatnio

Posty napisane przez PeterRiley


  1. Ustawa odróżnia proces przetwarzania i proces przechowywania.

    A przesyłanie danych przez klienta to "przetwarzanie" czy "przechowywanie"?

    Ani jedno ani drugie. Podane przez Ciebie przykłady to tylko zalecenia - "dobrze byłoby", "pożądane jest" itd. Podkreślmy jeszcze raz - przepisy nie nakazują sklepom stosowania SSL. Tylko Ty interpretujesz w ten sposób przepisy.

     

    Użytkownik je wpisuje i własnoręcznie klika "wyślij" ale to na tobie ciąży obowiązek zapewnienia tym danym bezpieczeństwo podczas przesyłania.
    Bzdura. Jak mogę być odpowiedzialny za dane, które do mnie nie dotarły? Podaj konkretny przepis, który mówi, że odpowiadam za dane od chwili wysłania ich przez użytkownika, a nie od chwili otrzymania ich przeze mnie. Jeśli nie znasz takiego przepisu, pozostaje "przechowywanie" i "przetwarzanie" które może zachodzić jedynie w przypadku posiadanych danych.

     

    Nie znam takiej sprawy osobiście, ale jak w końcu komuś wlepią karę za lekceważenie danych osobowych klientów to znając realia i tak będzie za mała żeby niektórzy zrozumieli.

    To może porozmawiamy kiedy pojawi się taka sprawa? Bo na razie Ty twierdzisz jedno, a wszystkie sądy i urzędy w Polsce co innego (skoro nikt nie został ukarany i nikomu nie nakazano używania SSL).

     

    To, że rzadko który sklep używa oznacza w/g ciebie że jest to niepotrzebne? Jeżeli masz takie podejście do swoich klientów to niechciałbym być twoim klientem.
    Nie twierdze ze jest niepotrzebne. Bardzo dobrze kiedy jest stosowane. Mowie tylko, ze zadne polskie przepisy nie nakazuja tego robic, co probujesz nam wmowic. Nie rozstrzygam teraz czy powinny to robic czy nie, mowie tylko ze na chwile obecna nie nakazuja i nie potrzeba prawnika zeby to zobaczyc.

     

    Przeczytałeś chociaż tę ustawę?

    Wielokrotnie. Nie ma tam słowa na temat szyfrowania danych na etapie przesyłania od klienta do firmy.

     

    "wyniki kontroli sklepów internetowych" i już możesz perzeczytać raport, z którego wynika, że na 200 kontrolowanych sklepów tylko 3 (słownie: trzy) spełniały wszystkie warunki kontroli.
    Czysta manipulacja. Oprócz szyfrowania wspomniano w tym raporcie również o szybkości odpowiedzi mailem - mamy rozumiec, ze to rowniez jest ujete w przepisach? Tam sa opisane wymagania co do idealnego sklepu, a to cos wiecej niz sklep dzialajacy zgodnie z prawem.

     

    Dziwią się strasznie, że po założeniu działalności trzeba jakieś zusy płacić, PITy rozliczać, a VAT to czarna magia.

    I tak samo jest ze sklepami. Myślą, że skoro warzywniak za rogiem nie musi mieć ssl to sklep internetowy też nie.

    Roznica jest taka ze ksiegowosc prowadzic trzeba, bo nakazuja to przepisy, a sady i urzedy moga ukarac za jej nie stosowanie, natomiast prawo nie nakazuje uzywania SSL.

     

    Podsumowujac, wymog prawny stosowania SSL jest Twoim poboznym zyczeniem. Fajnie jesli sklep go uzywa i na pewno bedzie to docenione przez klientow, ale nie jest to obowiazkiem. Pisanie wobec tego, ze firma nie ma prawa sprzedawac hostingu pod sklep bez SSL jest nieuczciwe w stosunku do tej firmy.


  2. W/g mnie stosownym środkiem technicznym (pewnie nie jedynym) jest właśnie protokół ssl i pewnie celowo ustawa nie precyzuje jakie to konkretnie środki techniczne ze względu na szybke zmiany w tej dziedzinie.

     

    Jeżeli nie ma ssl to jak *zapewnić* ochronę przed nieuprawnionym przetwarzaniem jeżeli dane osobowe z www lecą do serwera otwartym tekstem przez licho wie ile kabli po drodze?

    Mowa jest o przechowywaniu danych po ich otrzymaniu. Dane leca po kablu bo uzytkownik je wlasnorecznie wysyla, ale sklep odpowiada za nie dopiero w momencie gdy je otrzyma.

    Twierdzenie, ze przepisy nakazuja sklepom uzywanie protokolu SSL jest ogromnym naduzyciem. Po prostu wprowadzasz ludzi w blad i tyle.

     

    Rzadko ktory sklep czy uslugodawca internetowy uzywa SSL do wysylania danych klienta. Wskaz moze jakas sprawe, w ktorej sąd czy jakiś urząd nakazal sklepowi takie postepowanie.


  3. inne pliki systemowe - dopisywany jest rozszerzenie php, wiec raczej duzo sie nie pobawimy. Mogli jednak lepiej to zrobic.

    Instrukcja - wylaczasz na swoim serwie wykonywanie plikow php, zrodlo ma leciec jako plain text.

    Wgrywasz na swoj serwer skrypt skrypcik.php ktory ma sie odpalic u nich na serwie.

    Wykonujesz www.no-limit.pl/zamow/index.php?account=http://twojserwer/skrypcik

    Proste?

    Sprawdzilem, wyswietlilem w ten sposob konfig z haslami do SQL. Do bazy wiec tez jest dostep.


  4. Czy ktos moglby naskrobac cos o hostingu w no-limit.pl? Wprawdzie oferta wyglada niezle, ceny sa w miare przystepne (49.95 zł rocznie za konto BIZNES jest w sumie do przelkniecia), co najwazniejsze nie ma tych glupich limitow transferow. "Dodatkowe usprawnienia pomogą w usprawnianiu swoich witryn internetowych tak by niczego im nie brakowało i aby sprawnie działały one same" brzmi zachecajaco, tylko jedno mnie martwi, bo maja obok logo napisane "Profesjonalny Hosting Bez Obraniczen". Ciesze sie ze profesjonalny, ale niepokoja mnie te "obraniczenia". Czy to cos bardzo przydatnego? Czy moja strona moze sie obyc bez tych obraniczen?

     

    A tak poza tym to http://www.no-limit.pl/zamow/index.php?account=blabla


  5. Co nie zmienia faktu, że defaultowo powinno być ustawienie bezpieczne/logiczne/sensowne, czyli off. Jak ktoś już ma totalnie badziewny skrypt i koniecznie musi mieć on to wtedy sobie włączy.

    Tak, ale znajac realia mozna zrozumiec to ich defaultowe "on". Widze, ze sam dzwiek "register_globals" porusza tu jakas wrazliwa strune i zostalem zle zrozumiany. Niech sobie bedzie defaultowo on, byleby mozna bylo to, jak i inne opcje, zmienic.


  6. dzieki bogu w PHP6 nie bedzie w ogole takich potworkow jak register_globals i skonczy sie dzien dziecka dla nieudolnych programistow.

    To ciekawe po jakim czasie od publikacji doczekamy sie tej wersji w hostingu, eh.

     

    a hostingowcy? coz, chca sie dostosowac do wiekszosci i chca uniknac milionow telefonow typu "dlaczego moj syfiasto napisany skrypt nie działa". trudno im sie dziwic.

    To jasne, niech sobie ustawiaja register_globals=on, byleby dali mozliwosc indywidualnego wylaczenia.


  7. Panowie- o czym teraz dyskutujemy? O tym ze registar_ w i365.pl jest ON? Wielu dostawocow tak ma i problemu nie ma.

    Tak ma, ale umozliwia zmiane. Nie chodzi tylko o te opcje, to przyklad.

     

    Kwestie ustawien serwera pozostawmy jednak specjalistom ktorzy wiedza co robia.
    Nie zgodze sie. To nie jest opcja serwera, tylko php. Jest troche opcji w konfiguracji php, ktore wygodnie jest moc dostosowac do wlasnych potrzeb, a nie zostawiac "specjalistom", ktorzy czesto akurat na polu php (a czasem i na innych polach) poruszaja sie gorzej od nas. Inne firmy to rozumieja i pozwalaja dostosowac te ustawienia za pomoca php.ini lub .htaccess. Robilem strony dla roznych firm, korzystalem z roznych hostingow, ale z takim czyms spotykam sie pierwszy raz. Albo mialem szczescie, albo po prostu praktyka i standardem jest dopuszczenie konfiguracji przez uzytkownika podstawowych opcji php.

     

    Jak sie chce miec wlasna konfiguracje to co za problem- vps lub dedyk. Zamiast krytykowac (bo tak najlatwiej) moze przydalby sie test konta? Moze jednak mozna zmieniac? Ktoz to wie..

    Kupowac dedyka tylko po to, zeby miec mozliwosc zmiany kilku prostych opcji w php? ;) Na szczescie nie ma takiej potrzeby, bo takie podejscie do klienta firmy hostingowej odchodzi w przeszlosc.

    Jak wspomnialem wczesniej, i365 wprost napisał mi, że nie mozna zmieniac tych ustawien.


  8. @patryk: Ale moze home.pl dopuszcza zmiane tego parametru indywidualnie przez uzytkownikow? Nic nie mam przeciwko takiej opcji jako default (tak jest na wiekszosci hostingow) pod warunkiem umozliwienia uzytkownikom jej zmiany (tak tez jest na wiekszosci hostingow).

     

    @koliber2: Widze, ze Ty nie czytasz for roznych skryptow, moze dlatego ze masz problemy z czytaniem ze zrozumieniem, a zamiast tego wyskakujesz z obrazaniem innych? Akurat nie uzywam zadnych gotowych systemow. Nie chce mi sie dyskutowac tutaj czy register_globals jest czyms zlym czy nie, jak Ty czytales strony ktore to zalecaja to sobie stosuj u siebie. Widze, ze robisz za chcacego naprawiac swiat proroka ze sklonnoscia do reakcji na konkretne frazy w tekscie (register_globals) niezaleznie od kontekstu. Co do niewiedzy - wiem, do czego sluzy ta opcja i chce ja wylaczyc, jak pewnie wiekszosc uzytkownikow. Proste?

     

    Mi chodzi o to, ze w i365 nie mam mozliwosci wlasnorecznego dobrania podstawowych parametrow php. Register_globals to jedna z nich, ale przeciez sa i inne. Oczywiscie, mozna sobie z tym poradzic, ale to znacznie utrudnia prace. Z tego co widzialem korzystajac z uslug innych firm, mozliwosci zmiany tych ustawien przez lokalne php.ini czy .htaccess to standard, zdziwil mnie wiec brak takiej mozliwosci w i365 i dlatego o tym pisze.


  9. Zainteresowałem się tą ofertą po pochlebnych opiniach na forum i dopytałem ich o kilka rzeczy.

    Napisali mi, że nie ma możliwości globalnego ustawienia parametrów php na koncie. W standardowych opcjach są u nich takie kwiatki jak register_globals=On i nie dają możliwości zmiany tego ani w php.ini (jak np. superhost) ani .htaccess (jak np. webd).

     

    Reszta tutaj:

    http://don.i365.pl/phpinfo.php

    http://don.i365.pl/phpinfo.php5

     

    Jak dla mnie to całkowita dyskwalifikacja.


  10. Konto w WEBD, kilka tysięcy wizyt dziennie. Plik z logami z lipca zajmuje w tej chwili prawie 600 MB (wg informacji admina). Jest automatycznie pakowany gzipem. Po spakowaniu wazy ponad 30 MB. Sciagam go i probuje rozpakowac w windows. WinRar odpakowuje czesc i konczy komunikatem "CRC Error". Na koncu wypakowanej czesci pojawia sie sieczka (pomieszane fragmenty tekstow z pliku). Uzywajac 7-Zip otrzymuje podobny blad.

    GZip 1.2.4 (windows) i 1.3.5 (pod linuxem) przerywa w trakcie komunikatem "invalid compressed data--format violated".

    Proba odkompresowania za pomoca php5 (gzopen itd.) konczy sie na 128 MB.

    Spakowany plik sciagalem z serwera roznymi klientami FTP (oczywiscie w trybie binarnym) na kilku komputerach. Mniejsze pliki z logami z innych domen odpakowuja sie bez problemow.

    Kilkudniowa korespondencja z WEBD nie przyniosla rezultatu, caly czas twierdza ze u nich wszystko jest w porzadku.

    Jaka moze byc przyczyna? Jak dobrac sie do tych logow?


  11. Poza tym tez przylaczam sie do pytania - po co Ci akurat modul? Jesli chodzi o szybkosc to FastCGI z odpowiednim zapleczem sprzetowym (RAM) nie bedzie gorszy.

    Po doswiadczeniach z php5 cgi na WEBD. Byc moze przy odpowiedniej konfiguracji wszystko smiga, ale tam mialem problemy typu dlugie wczytywanie stron czy Internal Server Error od przypadku do przypadku. Natomiast PHP4 jako mod dziala tam bez zarzutu.

    Dlatego sie zrazilem do CGI.


  12. ROTFL ... nic dodać, nic ująć ... ROTFL !!! Pozostaje Ci zmienić hasło ... Pozdr.

    Nie wiem czy sie dobrze zrozumielismy - te polaczenia byly od uzytkownika, ktorego nie ma na liscie i nigdy nie byl przeze mnie dodawany. Hasla do panelu nikomu nie dawalem i bylo dosc trudne, stad podejrzenie ze ktos z firmy hostingowej maczal w tym palce.


  13. Napisz do supportu, mysle, ze to na pewno nie jest pracownik webd ( wszedłby odrazu ;-) ) tak więc ktoś poprostu próbowal sie dostać na Twoją strone ... Bierz IP i jesli Ci zalezy, to dowiec się, kim ta osoba jest.

    Wygląda na to, że nie tylko próbował ale i się dostał, bo nieudane próby nie są uwzględniane w statystykach.

    Support twierdzi, że nie posiada logów, ponieważ są na bieżąco kasowane.


  14. Tzn jak od innego użytkownika? W .htaccess określasz jednego usera ... Poproś o logi dostępu do Twojej strony z hasłem, porównaj IP i wszystko jasne ;-) Pozdr.

    W pliku passwd do tego katalogu jest jeden użytkownik - stworzony przeze mnie. W statystykach natomiast pojawia się kilkadziesiąt połączeń od wymienionego z nazwy innego użytkownika.

×