RobRobson: IDs schützen

Beitrag lesen

Hi nochmal :)

wähle nicht den GET-Request, lasse den Besucher erst über Los laufen, lasse ihn dann einen POST-Request absetzen auf einen zeitlich limitierten Zugang zur Ressource, der ihm auf der "Los-Seite" angeboten wird.

Schön und gut, aber einzige Schnittstelle ganz am Anfang ist und bleibt ein link. Was anderes als GET ist da nicht möglich.

Das ist im Prinzip das, was Du willst, läuft ohne Sessions und ein "Collect by Increment" ist nicht möglich.

Zeitlich limitiert wäre ja dann auch wieder sessionbound, was aber an sich nicht schlimm ist. Ich hab nichts gegen Sessions. Nur ist der Einstigspunkt zur Seite eben nur ein Link (von einer anderen Seite) der etwas bestimmtes aus meiner DB holen soll. Dazu kommt das ich drinnen nicht weiß das da daußen noch was rumschwirrt das irgendwann mal auf einen Inhalt zu greifen möchte. Also ich möchte keinen hash ablegen der wiederum ein Zeiger auf eine Id in einer wichtigen Tabelle ist. Ich denke auch das die zufälligen-einmalschlüssel von 'encoder' der beste Kompromiss ATM für mich ist.

Das Verfahren wird allerdings keinen Client (Roboter) davon abhalten, die Einstiegsseite genügend oft aufzurufen, um dann die Ressourcenkennungen in der Response zu erhalten.

Wenn, sagmal 10k oder 100k Datensätze vorliegen und als id ein md5 ähnlichen string hinterlegt ist (varchar 32), sollte die Chance gering sein das ein robot viel sinvolles rausbekommt. Zumal nach einigen versuchen iptables den Hahn abdreht.

Eine gute Methode ist es auchm einen zirkulären Verlauf einzubauen. Jeder Mensch wird den sofort bemerken. Dumme Robots hängen sich dabei gerne auf.

zirkuläre response meinst Du?

Viel Dank in die Nacht hinaus,
Rob