Zelfs voor mij, een concurrent, is het niets waard :-p

Klopt, weinig hosts hebben nu net specifiek eAccelerator, meestal gebruiken ze varianten.
Wij hebben in elk geval 1 server draaien waar dit op staat of stond, maar weet niet of dit er nog op staat.
De enige mogelijkheid is inderdaad je een webhoster uitzoeken die dit ondersteunt.

Hier zit je hoe dan ook toch beter

Klopt nieuwe lay-out staat klaar, maar komt niet zomaar op CP, onder meer omwille van grote complexiteit en andere naam die daar wordt gebruikt.

Topic achterliggende code is nog altijd 2500 regels, de fora details komen uit de database en zijn dus flexibel.

Robin: ik stuur je pb
Mag je ook altijd doen in het vervolg, via topic om een e-mail adres vragen is namelijk niet super effici?nt.

Blij dat jullie deze wijziging al goed vinden.
Bovendien zien jullie nog niet alles en is nog niet alles af

De topic's ga ik al beginnen doorvoeren, de rest van de sourcecode wijzigingen ga ik de dagen daarna doorvoeren.

Ps: de footer is ook herwerkt.
Ps 2: de komende dagen kan CP af en toe niet beschikbaar zijn, tijdens de updates - dit duurt telkens max een uurtje.
De reden voor de downtime is omdat we geen enkel risico willen lopen op corrupte data.
Dit is natuurlijk te vermeiden voor de criticasters onder jullie, maar ik doe het liever grondig, live, met grondig testen voor en nadien. Bovendien draait onze testserver met een andere configuratie dan de live server, waar meer is dichtgetimmerd.
Bedankt voor jullie begrip!

Ik kan niets van design, de blauwe zoekkader is wat het is geworden na crew feedback
Goed dat jullie het me nu vertellen.
Suggesties hiervoor hoe het beter kan zijn altijd welkom via pb!

Zo gaat het forum in de nieuwe CP eruit zien, ik heb er telkens commentaar bij gezet.
Mits jullie geen grote bezwaren hebben, zet ik het live.

Wijzigingen:

En zo wordt het uiteindelijk:

Feedback aub! (h)
Persoonlijk ben ik zeer tevreden, veel domme teksten en zaken werden opgelost.
Verder zit er nu zoekbox in.
Gelieve niet naar de menu's boven en links te kijken en er zeker niet op te reageren, zijn maar testen die voorlopig nog niet live komen.
Het gaat hier enkel over het forum.

Bedankt!

Gaat offtopic. :slotje:

CP v4.3 is nog niets van live gezet, alles staat momenteel in onze beta versie.
Hiervan kan dus zeker niets zijn doorgesijpeld.

Verder heb ik deze site overgekocht en niet gemaakt, bijgevolg kan ik onmogelijk alle details weten.
forum.php is bovendien een ongeloooofelijk groot en dom geprogrammeerd bestand. Het is al verschillende keren geoptimaliseerd (queries eerst), maar er blijven grote stukken rommel in staan.
Hoe dan ook is normaal gezien elke functie die niet wordt gebruikt ondertussen in commentaar geplaatst, volgende stap is dit opkuisen, maar het blijft een ziek grote php file.
Bovendien worden de parameters via rewrites enorm lastig in de file gezet.
(htaccess vormt eerst om, dan wordt de index geladen die de variabelen controleert en opkuist, dan de config voor db connectie en dan forum.php).

Ik weet absoluut niet alles en zeker niet van deze code, het is gewoon mega omslachtig gemaakt.
forum.php is bijna 2500 regels lang, met soms lange regels erin, veel if's en whiles.
Niet echt optimaal dus.

Er is een groot verschil tussen discriminatie en wat jij hier zegt.
Slaagt op niet veel hoor.
Discriminatie wordt tegenwoordig voor het minste gebruikt.
Bij de laatste sollicitatie ronde werd normaal niet naar het verleden gekeken.
Hoe dan ook ben ik wel van mening dat als je 1x je account laat hacken, dat er grote kans is dat je dat nogmaals doet.
Sommige mensen gebruiken overal hetzelfde wachtwoord of vullen hun wachtwoorden zomaar op elke site in.
Verder lock ik mijn computer als ik even weg ga, zelfs thuis.

Veiligheid voor iedereen is heel belangrijk voor ons, daarom dat we dit soort gedrag niet kunnen goedkeuren.
Heeft dus niets met discriminatie te maken.

Lars: als crewlid komt hij vermoedelijk niet terug, als gewoon lid misschien binnen enkele dagen.

En deze ROFL levert Niels 3 banpunten op (wat nog weinig is).
Als je niet constructief kan bijdragen en alleen maar mensen kan uitlachen, moet je hier niet de boel zitten verzieken.

Heb het al aan schoenzool gevraagd.
Hoe dan ook is het de bedoeling dat bugs verantwoordelijk worden gerapporteerd.
Zowel ik als Stefan zijn momenteel bezig met snel wat te testen, maar als we niet meteen iets kunnen vinden, laten we het voor wat het is.

Geen angst, ik was aan het testen of ik met de cookies iets kon forceren om aan crew topic's te komen, maar wat mij betreft is die test mislukt.
Ik kon er niet aan.
Je zou dan al echt een sessie van een moderator moeten stelen...

Voor zover ik weet wordt dit enkel in sessies gecontroleerd of je toegang mag hebben tot een bepaald topic of niet.
En sessies zijn enkel te vervalsen als je de sessieid van een crewlid hebt.
Ik zal de code nakijken, maar normaal zou je er niet in mogen kunnen.

Hoe dan ook moeten bugs correct gemeld worden privé, lees onze regels.
Dit kwestie van misbruik te vermeiden.

Een goede proxy lekt geen informatie en in dat geval ben je niets met je script dat kijkt naar ip ranges die intern worden gebruikt ^o)

Niels: hoe kun jij nu weten of ik over iets nadenk of niet?
Natuurlijk was ik er over aan het nadenken, anders meldde ik het niet in het topic. Als het een doodgewone log was en niet zo verdacht was, had ik er gewoon niets van gezegd op deze site. Wat mij betreft was het vrij snel duidelijk dat het Google Bom scenario niet kon.
En vanzodra ik een ip vond dat een proxy server was, heb ik dit hier ook meteen bevestigd.
Je uitspraak maakt insinuaties over hoe ik denk - en dat kun jij niet weten tenzij ik het je expliciet vertel...

Het is gebeurd met een account die was ingelogd als Lars, zo staat het in onze admin logs.
In de server access logs vind ik ook verwijzingen naar zijn ip.

Google is niet degene die het verkeer stuurde, de header (referrer) was gewoon vervalst.
Verder waren enkele van de ip's proxy servers en ga ik er dus vanuit dat het allemaal proxy servers waren (ook al kon ik er veel van niet terugvinden).
Vermoedelijk iemand die een grote privé proxy lijst heeft gekocht ergens.

Nog even benadrukken dat het voor ons onmogelijk is om te weten of iemand voor 100% betrouwbaar is of niet, we hebben onze sollicitatie vragen en een proefweek, waarbij we de logs van deze personen volgen, maar het is niet alsof we ze live en persoonlijk gaan bezoeken...
Is ook niet haalbaar voor een internet forum.

Statement van Lars: een vriend heeft mijn computer gebruikt terwijl ik even weg was om CP aan te vallen...
Niet professioneel.

Ik zeg niet dat ik expert ben, ik werkte als auditor om beveiliging te testen, dat is iets heel anders.
En de link naar jou script is gewoon iets om een ip met zekerheid te achterhalen. Iets wat in dit geval niet van toepassing was, want het waren allemaal anonieme proxies, een grote lijst zelfs.

Verder is het onmogelijk om alle proxies zomaar opeens te bannen.

Probleem lijkt opgelost, er komen geen nieuwe aanvallen meer bij.

Nee hoor, ik heb een script geschreven dat bepaalde aanvalsvectoren bant.
Verder copy paste ik gewoon de access logs in excel, filter de aanval er binnen de 10 seconden uit en ban zo 100'en ip's ineens.

Momenteel al honderden ip's verbannen

#!/bin/bash


if [ -f badips.txt ]
then
       for BAD_IP in `cat badips.txt`
       do
               iptables -A INPUT -s $BAD_IP -j DROP
       done
else
       echo "Can't read badips.txt"
fi

Jgdonleach: ik en iedereen die meegewerkt heeft met CP scripting kan je verzekeren, en ik wil het in bloed schrijven, dat de online leden teller klopt.

Verder wil ik hierbij ook bevestigen dat de verzoeken inderdaad werden geplaatst met vervalste headers.
De ip's zijn niet afkomstig van Google maar van proxy servers.
Er werd een extra controle ingevoerd en proxy servers worden nu vrij snel herkend en automatisch geband.

De snelheid van de site zou nu weer moeten verbeteren.

Nogmaals sorry voor de last.

In dit geval snapte ik er niet meteen iets van, de verzoeken zouden moeten worden geblokkeerd, maar om een onbekende reden doet die klote server het niet.
Het enige dat ik kan zien is dat er gewoon te veel verzoeken komen vanuit verschillende ip's en vermoedelijk doet de server er daarom niets tegen.

Bovendien lijkt de grote verschijdenheid aan ip's (638 tot nu toe, telkens max 3 verzoeken per ip), met allemaal google als referrer, eerder op een fout ergens in Google, of een heel groot ip bestand/botnet...
Ik heb al wel aanvallen gezien, maar nooit groter dan een 100-tal ip's...
Weinig scriptkiddies hebben zoveel verschillende ip's...
Zelfs op dit moment krijg ik elke seconde enorm veel requests komende vanuit google als referrer...

De server zou nu meer verzoeken aan moeten kunnen, had de server ingesteld op een 200-tal verzoeken toestaan, kwestie dat we dat toch nooit haalden (tot nu).