AMA-Foodblog-Award: Ende des Votings nach User-Manipulation

normalerweise muß man den blog sofort beenden. egal wer sieger ist, der wird gebast, soviel ist sicher!!! die 5000 euro gehören karitativ gespendet. und die it-beauftragen auf schadenersatz verklagt!

Oder werfen sie hier einfach mit unzusammenhängenden Sätzen ?

Sicher voll fett weil ja Socialmedia.
Und dann 3 Dr.Rolands angeheuert die das zusammenschustern für 12 EUR/h.

Find ich aber eigentlich gut.. Ich finds auch immer unfair wenn die teilnehmer auf Facebook Leute animieren für ihr bild zu Voten.. ganz egal ob es gut oder schlecht ist...

"das Voting sei nach allen bekannten Sicherheitskriterien implementiert worden" ist eine glatte Lüge.

Im Quelltext sind noch Reste der Voting-Funktion drin - da wird per Ajax an "vip.php" ein Request abgeschickt der die Clientseitig "ermittelte" IP-Adresse und die ID des Blogs für gestimmt werden soll übermittelt.

Die IP-Adresse wurde serverseitig ermittelt und in ein HTML-Element mit der ID "iip" geschrieben, von dort aus mit JavaScript gelesen und wieder zurück an den Server geschickt.

Wenn man schon die IP-Adresse als Eindeutigkeitskriterium für die Bewertung verwendet, sollte man diese gefälligst nur serverseitig ermitteln und prüfen.

Wer auch immer das programmiert hat, sollte den Beruf wechseln - aber flott.

"pay peanuts and you get monkeys"

so wie immer, war dieses Projekt sicher unglaublich wichtig und musste besser gestern als morgen live gehen. Und wenn man den Programmierern nichts zahlt, sind die wahrscheinlich auch wenig gewillt Überstunden zu schieben. Doppeltes Laden von Plugins und Code-Leichen sprechen für diese Theorie ^^ ...oder es war der Praktikant.

danke für den Lacher!

ihr haben die irgendein voting "script" verwendet oder das selbst verbrochen?

kann sein, dass die irgendein ein script verwendet haben, und das irgendwie selber angepasst/ins typo3 reingenudelt haben, und das auch noch stümperhaft.
dafür spricht, dass die v.php offensichtlich im webroot liegt, was absolut nicht den guidelines für typo3-programmierung entspricht.

Ich denke die haben das selbst verbrochen - eine fertige TYPO3-Extension war es jedenfalls nicht - das würde man deutlich sehen :)

Nachtrag: von TYPO3 hat derjenige, der die Site umgesetzt hat jedenfalls auch nicht viel Ahnung.

no_cache=1 in der Adresszeile ist ein ziemlich eindeutiges Zeichen dafür

Ich finde keine Worte für meinen Ärger, es gibt immer wieder "Agenturen" die keine Ahnung von dem haben was sie tun, aber fest IT-Dienstleistungen verkaufen und dafür auch noch (viel) Geld für absolut schlechte Arbeit verlangen.

3. Weiterleitung der Startseite auf 'home/?no_cache=1'
4. popelige css-hacks statt ordentlicher/echter browserweiche
5. jquery 1.7.1 UND 1.7.2 wird geladen, WTF???
6. hintergrundgrafik mit über 200kb!!!
7. prefixComments offensichtlich unbekannt, sonst hätte man das abgedreht in css_styled_content.
8. der code für den ticker könnte auch 3 fantastillarden zeilen code haben. geht aber auch in 10 zeilen ... dann ruckelt er vielleicht nimmer so grauslich.
9. eine .htaccess datei im ordner typo3/install/ wär auch nit schlecht.
10. das mit dem spamschutz für mailadressen haut auch nicht ganz hin, siehe impressum. *lol*

das waren jetzt mal 10 minuten, ohne zugang. man ahnt schreckliches ... ;)

Nachtrag:

In localconf.php den Wert "install" aus $TYPO3_CONF_VARS['EXT']['extList'] streiche ist ab 4.5 ebenfalls kein Fehler - mit einem be_user kann man sonst ohne Probleme Zugriff auf das Install-Tool erlangen, weil man ja das ENABLE_INSTALL_TOOL-File im Backend auch ohne Zugriff aufs Filesystem anlegen kann.

naja, ob das oder .htaccess mit htpasswd ist dann auch schon wurscht.
und die ENABLE_ ... kann nur ein admin anlegen AFAIK. (wobei ich als admin das noch nie als redakteur versucht hab ;))

Als redaktuer darfst du es nicht anlegen, richtig - aber es gibt immer wieder Fälle wo der Kunde einen Admin-Benutzer fürs Backend möchte wo dann die Benutzerdaten in der halben Firma herumgereicht werden. Da ist es schon praktisch, wenn man Ohne Filesystemzugriff nicht ins Install-Tool kommt.

admin user für endkunden gibt es bei mir nur ohne hosting/wartung/betrieb (read: never ever). ;)
wenn einer einen admin will, dann muss er sich seinen sch*** selber machen (aka fire-and-forget projekte). SLAs kannst mit admin-zugang beim kunden einfach nicht machen, halte ich für unternehmerisch grob fahrlässig wenn man das doch macht.

Ein Admin-Zugang wird hier auch nicht leichtfertig rausgegeben, da darf der Kunde vorher eine Erklärung unterschreiben, dass er für sein Zeug selbst verantwortlich ist, sobald der Zugang draußen ist.

hihi, so ein dokument hab ich auch: der kunde erklärt ausdrücklich, dass er tiefgehende kenntnisse in xhtml 1 transitional sowie html 5, css2 aufwärts und javascript hat und sich mit wartung und betrieb von datenbank-gestützten internet-anwendungen auskennt ... uswusf. bis hin zu verschlüsselungstechniken (password safe, md5, salts und hashes ...)
das reicht meist als abschreckung, die meisten wollen dann eh keinen admin mehr. sie haben ja auch meist eigentlich gar kein argument dafür. rechte wollen sie alle, pflichten möglichst keine ... n00bs

Ja so ist das wahre Leben ... wenns gut geht, wollen viele den Staat loswerden, doch in schlechten Zeiten wird gleich nach Hilfe gerufen ... schon faszinierend, was für Menschen unter den Steinen so hervorgekrochen kommen ;-)

Ich hatte einige der von dir genannten Punkte schon im Kommentarfenster, hab' sie aber wieder entfernt, weil ich nicht g'schert sein wollte :)

Zum Thema CSS-Hacks muss ich aber eins loswerden:

* html und *:first-child+html und #a#b sind durchaus angebrachte Hacks - Sie halten das CSS übersichtlich (wenn mann denn noch den IE6, 7 und 8 unterstützt).

Was ich heir absurd finde ist der Einsatz von Conditional Comments - noch dazu der Kommentar drüber

"<!-- Older IE stylesheet, to reposition navigation arrows, added AFTER the theme stylesheet above -->"

Der ist fast noch cooler:

<!--[if lte IE 8]>
<style type="text/css">
</style>
<![endif]-->

Das jQuery-Easing-Plugin ist übrigens auch 2x eingebunden :D

aber generell mag ich beide arten von hacks nicht übermässig.
kommt halt auf die menge an. grosse projekte mit lauter hacks in zig verschiedenen css dateien, da wird die x-browser anpassung auf kommenden versionen ein mords spass.
von daher: die meisten hacks lassen sich eh vermeiden (ie6 lassen wir mal weg), und für richtig böse sachen ist eine zusätzliche kleine css datei je "browser", die per javascript nachgeladen wird imho die sauberere lösung. vorallem weil man die browserweiche dann nicht auf user-agent aufbauen kann, sondern auf tatsächlichen fähigkeiten des browsers abfragen kann. das sollte dann auch die zukunftssicherheit positiv beeinflussen.

auf manchen seiten muss man das halt.
nicht zuletzt wegen der pagerenderer bugs/missing features, der in der LTS immernoch drin ist (bei usr_int plugins verweigert der pagerenderer addCSS/addJS, was im klartext bedeutet: entweder caching gleich auf der ganzen seite (id=XY, nicht auf der ganzen website!!) abdrehen, oder die 'alte' methode nehmen zum hinzufügen und auf automatisierte compression/concatenation von js und css verzichten).
sollt halt nicht die startseite oder eine andere frequentierte landing-page sein.
man könnte es auch einfach aus der adresszeile entfernen.

Das Caching abdrehen ist auch kein Problem - aber das macht man nicht per config.no_cache=1 sondern indem man seine Plugins anstatt als USER eben mit USER_INT einbindet und dann eben auf die neuen Compressor-Routinen verzichtet.

Das ist wirklich ein Kreuz, weil man den Cache für die generierten CSS- und JavaScript-Files manuell löschen darf, wenn er mal wieder hängt :) - aber in dem Fall spielt das keine Rolle, die Site verwendet nicht den 4.5-LTS-Release sondern 4.7, da funktioniert die Sache recht zuverlässig :)

das no_cache=1 kommt auch in die (eine) url, wenn man es auf einer einzigen seite in den seiteneingenschaften einstellt, dass diese eine seite mit der uid xy nicht gecached werden darf.
und mit cooluri z.b. kann man es einfach aus der url entfernen, dann fällts so gscherten wie uns nicht auf. ;)
und auf die neuen compressionen (so neu sind die auch nicht, ich hab die schon seit 4.3 via extension im einsatz) kann man nicht immer verzichten.
wenn's aber eh individualprogrammiert ist, spricht ja nix dagegen, die css und js dateien global via page-object einzubinden.
auf user_int und coa_int bin ich generell nicht gut zu sprechen. ;) is aber sicher geschmacksache.

Ja, man kann dasselbe auch bei RealURL machen (hier ist übrigens ziemlich sicher RealURL im Einsatz:
http://www.foodblogaward.at/typo3conf... l_conf.php liefert kein 404

http://www.foodblogaward.at/typo3conf... /ChangeLog

529 HTTP-Requests Anfragen (9,51 MiB) sind übrigens auch nicht schlecht für die Gallerie-Seite :D