kafi

A niektórzy nie życzą sobie oglądania ogłoszeń dotyczących prania brudnych pieniędzy

Zapisuj ciastko sesyjne z adnotacją, że user już głosował. Druga metoda to - w momencie generowania formularza generujesz też jakiegoś hasza, zapisujesz go do bazy i dodajesz do owego formularza jako ukryte pole. W momencie aktualizacji (w sumie bezpośrednio przed nią) sprawdzasz, czy hasz istnieje, a po dokonaniu aktualizacji usuwasz go z bazy. W ten sposób wyeliminujesz odświeżanie przez f5 (bo żeby móc wysłać jeszcze raz formularz, to trzeba go od nowa ściągnąć).

No to googlując te twoje dowody... http://www.gra-metin.pun.pl/viewtopic.php?pid=1540 Trzeba to jakoś komentować?

Cóż, hdmagc zacytował po prostu kawałek tekstu ze strony... active-hosting.pl Więc to chyba twoim zadaniem jest prostować informacje zawarte, jak by nie patrzeć, na oficjalnej stronie... Screen: http://prntscr.com/27bs0

Dane firmy to nie są dane osobowe!

Ewentualnie tylko oferty sponsorowania kogoś, a nie bycia sponsorowanym przez kogoś. Oczywiście moderowane, co by ktoś nie robił sobie pod przykrywką sponsorowania jakiegoś wakacyjnego krzaka. A prośby o_sponsoring to cóż, wypadało by napisać do oferentów jakieś podanie i liczyć na to, że się nie będzie zlanym.

A ciebie to obowiązki ping/trace nie dotyczą? C:\Users\Konrad>tracert hostdell.pl Nie można rozpoznać nazwy systemu docelowego hostdell.pl. C:\Users\Konrad>nslookup -type=NS hostdell.pl a-dns.pl Serwer: UnKnown Address: 195.187.245.44 hostdell.pl nameserver = ns1.one.czest.pl hostdell.pl nameserver = ns2.one.czest.pl C:\Users\Konrad> C:\Users\Konrad>ping ns1.one.czest.pl Badanie ns1.one.czest.pl [91.210.242.165] z 32 bajtami danych: Odpowiedź z 91.210.242.165: bajtów=32 czas=582ms TTL=58 Odpowiedź z 91.210.242.165: bajtów=32 czas=465ms TTL=58 Odpowiedź z 91.210.242.165: bajtów=32 czas=222ms TTL=58 Odpowiedź z 91.210.242.165: bajtów=32 czas=951ms TTL=58 Statystyka badania ping dla 91.210.242.165: Pakiety: Wysłane = 4, Odebrane = 4, Utracone = 0 (0% straty), Szacunkowy czas błądzenia pakietów w millisekundach: Minimum = 222 ms, Maksimum = 951 ms, Czas średni = 555 ms C:\Users\Konrad>nslookup hostdell.pl 91.210.212.165 DNS request timed out. timeout was 2 seconds. Serwer: UnKnown Address: 91.210.212.165 DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. DNS request timed out. timeout was 2 seconds. *** Upłynął limit czasu żądania dotyczącego UnKnown C:\Users\Konrad>

Całe awantury polegają na tym, że pojęcie support rozumie każdy po swojemu. I w sumie bez szczegółowych danych co owy "support" robi, to informacja o nim jest bezsensowna. W porządnych "CC" mamy z przodu frontendową warstwę (którą w sumie równie dobrze zastąpił by ivr'owy kreator ), następnie techniczną obsługę klienta (ci mają już jakąś tam wiedzę i jakieś drobne uprawnienia do zrobienia czegoś) no i ekipę NOC/NMC/SMC/czy jak to jeszcze inaczej tam nazwać, która to zajmuje się dbaniem o jakość usługi. I teraz - owy "support" niektórzy rozumieją jako dwie pierwsze warstwy, a dla innych to także i trzecia. Bo pisanie, że skoro nikt nie odbiera "infolinii" to znaczy, że nikt nie siedzi i nie obserwuje serwerów to takie lekko krzywdzące dla takich firm jest...

iptables -A OUTPUT -p tcp --dport 110 -j LOG --log-prefix sledzik --log-uid Potem cat /var/log/messages | grep sledzik Będziesz miał UID/GID szkodnika, który owe połączenia wykonał.

Obstawiam, że owa obsługa charytatywnie tego nie zrobi, a chyba o to autorowi chodzi... Ale bez dostępu do jakiegoś terminala z uprawnieniami roota to raczej nie będzie wykonalne zadanie...

Zacznij może przerzucać, to może pomoże... A tak serio mówiąc - pewnie przetwarzanie danych w tej firmie realizowne jest w jakiś z lekka rozproszony sposób i zanim dane z serwera FTP dotrą do magazynku używanego przez serwer WWW to troszkę czasu mija.

Dowolna edycja nie implikuje przypadkiem edycji dowolnego elementu owego szablonu, w tym także i stopki?

Crazyluki - może i ma podpięte; ale jeśli użytkownik zlecenie wyśle przez panel, to istnieje pewność autoryzacji loginem/hasłem i wiadomo, co to za jegomość. Jak wyśle maila, to trzeba się troszkę nagłowić, kto to też mógł napisać (a często zdarza się, że maile przychodzą z nieznanych adresów, do tego jeszcze niepodpisane) i czy to na prawdę on (fałszować nagłówki wcale nie tak trudno przecież...). Więc te dwie formy (jeśli ofc. owe tickety działają tak, jak napisałem są tyci rozróżnialne i do jednego worka wrzucać się ich nie powinno).

Nadawaj uprawnienia do poszczególnych baz danych, a nie globalne

Ano taka (jeśli owy TICKET oznacza zgłoszenie przez panel billingowy), że omijamy jak by nie patrzeć sprawy autoryzacyjne (bo autoryzacja po adresie e-mail czy numerze telefonu clip to w sumie żadna autoryzacja)...

http://store.ovi.com/content/21652#/content/21652

Na serwis, który co rusz to na jakimś rbl'u występuje?

No i co w związku z tym?

Powiedz mi, jaka to usługa ma odebrać przychodzące żądanie skanowania i je obsłużyć? Jak łączysz się przez USB, to sterownik się pewnie tym zajmuje. A w przypadku ethernetu CO? Na każdym komputerze, który ma mieć możliwość obsługi skanera powinien być postawiony jakiś SERWER, który będzie sobie słuchał i ewentualnie obrabiał przychodzące dane. Szybkie pytanie - masz URUCHOMIONY i SKONFIGUROWANY na komputerze Menedżer Skanowania Samsung? To NIE jest to samo, co sterownik WYDRUKU.

Miłoszu - taki wniosek zostanie z miejsca odrzucony. Bo twoje widzimisię nie jest racjonalnym powodem do marnotrawienia adresacji (odpowiedź będzie w stylu - użyj domain-based-vhosts w twoim serwerze WWW).

To raczej ty źle opisujesz coś, co być może realizowane jest inną technologią. DNSy nigdy nie stanowią jakiegokolwiek firewalla. Bo serwer DNS nie widzi, kto tak w sumie pyta. Bo pyta resolver, który ma tam jakieś sobie IP niekoniecznie powiązane z userowym endpointem. Wycięcie na poziomie usługi dns [czy to zwracanie nxdomain, czy to nie zwracanie niczego] może być też realizowane tylko dla resolverów, a nie poszczególnych endpointów. Więc jakiekolwiek zliczanie odwołań przy pomocy analizy requestów DNS to wytnie... ale resolver googlowy czy tam tepsowy, bo z nich będzie lawina requestów. Natomiast jeśli to, co opisujesz, to działa jako serwer proxy [i owe "przekierowanie domeny na ich dnsy" to przekierowanie na taki balancer/proxy] to wtedy owszem, co nieco można wyciąć. Dowcip tylko taki, że większość ddosów to jednak idzie kierowanych na adres IP a nie na domenę

56 ataków to ciężko nazwać ddosem... Gdyby to była kwestia takiego wolumenu, to oni sami pewnie by to wyrżnęli na poczekaniu. Tu raczej mowa o paruset tysiącach połączeń z zupełnie różnych klas IPków. A tego sensownie przy iptables na VPSie się nie wyrżnie. Nie ma bata. Musi to być jakiś dedykowany frontendowy fw. A poza tym pomyśl sobie, co ci da monitorowanie DNSów. Przecież większość implementacji resolverów cacheuje odpowiedzi. Ba. Rzadko zdarza się, aby klient-ZU był jednocześnie swoim resolverem. Więc raczej wyrżnięcie tych adresów nic ci nie pomoże... A w przypływie geniuszu wytniesz 8.8.8.8 i 194.204.159.1 (bo z nich np. będą częste odpytki) i będziesz narzekał że strona nie działa ci z połowy świata i połowy Polski...

http://www.webhostingtalk.pl/topic/30863-jak-to-jest-d/ Dziwny zbieg okoliczności?

No sensowny sprzętowy firewall, który jest w stanie zagregować taki masowy ruch to spory wydatek, więc nie ma się co dziwić, że dla jednego problematycznego klienta nie będą tego 100% sponsorować, tylko odbiją sobie na kliencie. Szczerze mówiąc (nie wiem, jak to jest tam zrobione i jaka to usługa), to na miejscu firmy to bym nullroutował takie IP do czasu, aż ddos się uspokoi i właściwie tyle. Chyba, że klient zasponsoruje firewalla

Taka mała wskazówka: drukowanie to wysyłkę pakietów zaczyna KOMPUTER, odbiera DRUKARKA. W przypadku zdalnego skanowania, to wysyłkę zaczyna DRUKARKA, odbiera KOMPUTER. Może więc na komputerze jest jakaś zapora, która nie przyjmuje zdalnych połączeń? Spróbuj do celów debugowania powyłączać wszelakiego rodzaju zapory, antywirusy, pakiety internet security itp.