Losemenge.de - Mindestlosemenge, Loseumlauf, Losevernichtung, Kontostände von mehr als 40 Projekten!

@chrissel: wenn du Zeit & Lust hast, wär evtl. noch so'n Twitter Dingens und 'ne Facebook Seite (gefällt mir etc.) ganz praktisch. K.a. ob sich da viele Klammlose User rumtreiben, aber evtl. erreicht man dann den Ein oder Anderen mehr ;)

schaden kann es auf jeden Fall nicht. wenn jemand noch ein wenig Werbung für dieses Projekt buchen möchte würde ich mich mit 10MIO daran beteiligen!
Bitte nur per PN bescheid sagen.
 
Hab mal ein paar Textlinks bei Klamm gebucht.

Code:
#60436 :: Losemenge.de -Hilf mit!
http: //www.losemenge.de/ (Lose Seiten)
3/30.000 Views :: 0 Klicks (0,00%)
 
Traut sich kein Betreiber mehr, seinen EF "anzuschließen"? :ugly:

Scheint so :-?

Hier wurde ja von einem User bereits gesagt, dass ihr User von Klammseiten ja in den Threads mal fragen könnt, ob die Seite bei Losemenge.de teilnimmt und ihr das cool fändet oder so.. das sollte nämlich dann wohl nicht als Spam durchgehen und könnte eventuell noch ein paar EF's einbringen!

Also ein "Wie schaut es hier mit Losemenge.de aus? Wird da mitgemacht? Wäre doch ganz cool!" von euch (!!) bei Seiten bei denen ihr angemeldet seid könnte denke ich schon ein wenig bewirken.
 
Script für FWX

Hi.

chrissel, hab deine PN bekommen und gelesen, ABER:

Ich hatte mir das Script für das FWX etwas anders vorgestellt. Ich möchte keinesfalls, das ein Script im FWX in der Lage ist, Lose irgendwohin zu senden und/oder zu holen. Das hat jetzt ansich nichts mit dir oder deinem Projekt zu tun, das ist ne ganz allgemeine Geschichte. Zum Einen wird hoffentlich jeder Webmaster einen großen Teil der Lose die ihm zur Verwaltung gegeben wurden, in den Tresor verschoben haben und auch da belassen, solang kein Bedarf ist, diese wieder rauszuholen. Das würde ja schonmal die gezählte Menge bei deinem Projekt etwas nach oben bringen, aber doch völlig falsche Aussagen treffen.
Zum Anderen ist es ja so, das immer wieder *schlimme Finger* versuchen Lücken in den Seiten auszunutzen. Und wenn dann gar auf einer Seite ein Script eingebunden ist, welches ganz legal Lose vom EF woanders hinsenden kann, wird es nicht lange dauern, bis die ersten ganz wild am Klimpern sind und alles versuchen werden, dann mal ganz *legal* anders zu transferieren. Es muss dann noch nichtmal das eingebundene Script selbst sein, welches die Lücke aufweist, sondern kann jedes andere Script sein was installiert wurde.

Von den XXX Admins einer Seite haben nur ein kleiner Prozentsatz auch wirklich Ahnung was geschieht, wenn sie ein Addon installieren.
Und Admin XYZ bekommt ein *hammergeiles Addon* für günstig, installiert, Lose vom EF weg.
Das wäre auch nur eine Variante, gibt da wohl noch xxx andere Szenarien, was da passieren könnte.

Ein Script, welches die entsprechenden Daten im FWX ausliest (EF-Stand) und per Cron(Cron der FWX-Seite, da man ja sonst wieder ein PW oder so rausgeben müsste) an deine DB sendet, wäre vielleicht nicht ganz so genau, evtl. auch manipulierbar, aber auf jeden Fall sicherer.

Vielleicht findest du oder ein pfiffiger zuverlässiger Progger da iwie einen Mittelweg.
Sollte dies dann soweit sein, wäre ich auch gern wieder bereit, teilzunehmen.

LG p666p

ps: ich glaube da denken einige so
pps: es gibt ein Script von Wichtel, wo EF-Stand und EF-Transaktionen ausgelesen werden, vielleicht kann man sich mit ihm kurzschließen und da was entwickeln ?
 
pps: es gibt ein Script von Wichtel, wo EF-Stand und EF-Transaktionen ausgelesen werden, vielleicht kann man sich mit ihm kurzschließen und da was entwickeln ?

Es bleibt immer das gleiche Problem.
Jede ausgelesen Menge, die direkt an Chrissels Server geschickt wird und nicht direkt vom klamm-Server stammt, ist manipulierbar und führt das Projekt ad absurdum.

Aus diesem Grund ist der Umweg über einen Klammaccount unausweichlich. Ein EF-Statistik-PW wird es niemals geben.
Wer das FWX Addon nicht einsetzen möchte, kann sich auch ein eigenes Script schreiben, das die Lose hin und her transferiert. Kommt aber aufs gleiche raus.

Fazit: Entweder es vertrauen einige Betreiber auf dieses Konzept und nehmen daran teil, oder das Projekt muss leider als gescheitert angesehen werden.
Klingt hart, ist aber leider so.
 
Ich möchte keinesfalls, das ein Script im FWX in der Lage ist, Lose irgendwohin zu senden und/oder zu holen.

du hast aber schon gesehen, dass die Lose nicht irgendwohin gehen, sondern auf dein Klamm-Konto?
Und von da auch wieder auf deinen EF?
Du verlierst nie die Kontrolle über deinen EF oder deine Lose, auch führt Losemenge keine Transaktionen für dich aus sondern bittet dich nur diese durchzuführen.



Man kann die EF-API ja über SSL ansprechen, ich werde mal die Tage schauen, ob man, wenn man SSL selbst teilweise implementiert, die Daten der Schnittstelle direkt an den Losemenge-Server übergeben kann. Denn SSL gewährleistet die Integrität der Daten.
Ich vermute aber mal, dass es zuviel Aufwand ist.
 
Man kann die EF-API ja über SSL ansprechen,

Falls du mit EF-API klamm.de/engine/ meinst wird das denke ich nichts bringen. Denn alle EF-Klassen die ich bisher gesehen habe arbeiten ohne SSL, und das hat bisher auch immer gereicht.

ich werde mal die Tage schauen, ob man, wenn man SSL selbst teilweise implementiert, die Daten der Schnittstelle direkt an den Losemenge-Server übergeben kann. Denn SSL gewährleistet die Integrität der Daten.

Was meinst du mit "Daten der Schnittstelle direkt an den Losemenge-Server"? Wieder meine erste Idee, bei der ich die EF-ID und das PW bekomme und selber den Konto- und Tresorstand auslese?
Da hatte ich doch schon eine RSA-Verschlüsslung zur Übermittlung der Daten. Aber Problem ist dabei ja nun mal, dass ich (oder jemand der Serverzugriff hat) mit den Daten alles mögliche anstellen könnte..
 
Falls du mit EF-API klamm.de/engine/ meinst wird das denke ich nichts bringen. Denn alle EF-Klassen die ich bisher gesehen habe arbeiten ohne SSL, und das hat bisher auch immer gereicht.
nur weil andere Klassen es ohne SSL machen, muss man es nicht genauso machen ;)
Die EF-API lässt sich über SSL ansprechen und das mache ich immer so (Schutz vor MITM):
https://www.klamm.de/engine/lose/efstatus.php

Was meinst du mit "Daten der Schnittstelle direkt an den Losemenge-Server"?
wenn Daten über SSL ausgetauscht werden, greifen gewisse Schutzfunktionen für sichere Datenverbindungen (Vertraulichkeit, Authentizität, Integrität).
Der Browser muss z.B. überprüfen können, dass er wirklich mit deiner Bank kommuniziert und auch dass die Anfrage nicht auf dem Weg zum Browser verändert wurde.
Und genau das will ich mir ansehen, ob man es ausnutzen kann:
Wie schwierig ist es die simpelste SSL-Implementation in PHP zu schreiben? Man könnte dann den EF-Server kontaktieren, loggen welche Daten er zurückschickt und die an den Losemenge-Server schicken.
Der kann dann dank der Integrität und Authentizität überprüfen, ob die Daten wirklich vom EF-Server kamen und ob sie verändert wurden.
Wenn du es nicht ganz nachvollziehen kannst, ist nicht ganz schlimm ;) Das ist ein seeeehr tiefes Abtauchen in die Kryptographie und SSL.
Eine vollständige Erklärung wie meine Idee funktioniert und warum auf welcher Technik würde gerade etwas meine Zeit sprengen, und die Länge dieses Posts :LOL:
Ich bin mir auch noch nicht sicher ob es zu 100% funktioniert, das ist von der genauen SSL-Spezifikation abhängig, in der Theorie könnte es aber gehen.

Wieder meine erste Idee, bei der ich die EF-ID und das PW bekomme und selber den Konto- und Tresorstand auslese?
Da hatte ich doch schon eine RSA-Verschlüsslung zur Übermittlung der Daten. Aber Problem ist dabei ja nun mal, dass ich (oder jemand der Serverzugriff hat) mit den Daten alles mögliche anstellen könnte..
nein, es würde nur die Antwort und einige Daten der SSL-Verbindung übermittelt werden, um die Antwort validieren zu können.
Ich weiß noch nicht ganz ob es geht, weil ich nicht weiß, ob die Antwort auch nochmal einen Fingerprint zur Integritätsprüfung enthält oder nur der ausgetauschte Schlüssel zur symmetrischen Verschlüsselung in dem asymetrischen SSL (hybride Verschlüsselung).
 
nur weil andere Klassen es ohne SSL machen, muss man es nicht genauso machen ;)

Klar, da hast du völlig Recht. Aber wäre das alleine deine Idee gewesen wäre ich nun nicht davon ausgegangen, dass dadurch mehr Seitenbetreiber mitgemacht hätten, da sie vorher auch schon immer jegliche SSL-Nutzung nicht vorausgesetzt haben in ihren Scripts.


nein, es würde nur die Antwort und einige Daten der SSL-Verbindung übermittelt werden, um die Antwort validieren zu können.

Du hast also vor, dass das Script auf Server X per SSL die EF-Abfrage durchführt und die Daten die zurückkommen und noch nicht wieder entschlüsselt werden, werden direkt auf dem Losemenge-Server geleitet und dort wird es entschlüsselt?
Hört sich nach einer sehr interessanten Idee an, denn gefakte Daten wird Server X ja sicherlich nicht richtig verschlüsseln können, so wie es die EF-Server machen.

Ich weiß noch nicht ganz ob es geht, weil ich nicht weiß, ob die Antwort auch nochmal einen Fingerprint zur Integritätsprüfung enthält oder nur der ausgetauschte Schlüssel zur symmetrischen Verschlüsselung in dem asymetrischen SSL (hybride Verschlüsselung).

Damit meinst du, dass du dir nicht sicher bist ob auch nur der Server an dem die Daten eigentlich gehen (also in diesem Falle der Server X) die Daten entschlüsseln kann? Und somit eine Weiterleitung zum Losemenge-Server sinnlos wäre, da dieser diese Daten nicht entschlüsseln kann?

Wenn dem so wäre, wäre es natürlich ziemlich ärgerlich für die schöne Idee die du hast.