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

[noname86]

In den FAQs steht, dass die eigene Losemenge erst nach und nach zur Gesamtmenge hinzugezählt wird.

Was soll das für ein Sinn haben?

damit keiner nachvollziehen kann, wem die lose gehört haben, ich versteh den sinn aber auch gerade nicht, da man ja nirgendwo sieht, wer mitmacht

 

[Stoffi]

Wann werden die Konten eigentlich abgefragt? Gibts da eine bestimmte Uhrzeit am Tag?

 

[chrissel]

In den FAQs steht, dass die eigene Losemenge erst nach und nach zur Gesamtmenge hinzugezählt wird.

Was soll das für ein Sinn haben?

Um den Sprung bei der Teilnahme eines größeren EFs/klamm-Acc's geringer zu halten.
Wenn nun die EF-Anzeige sich um 3 erhöht und auf einen Schlag dort sagen wir mal 400 MRD drauf kommen sieht man, dass es Benutzer gibt, die eine große Summe auf sich bündeln. Wenn da dann nur 20 oder max 40 MRD drauf kommen könnten diese auch durch Transaktionen auf den anderen Konten auf einmal mit einbezogen werden.. öh ja
Dazu meine ich, dass der damalige Losemenge.de-Betreiber meinte, dass es dort so etwas ähnliches schon gab, da es einige Seitenbetreiber wohl gewünscht hatten.

Aber ehrlich gesagt: Das habe ich so vor mehreren Monaten eingebaut als ich mal mit der Seite anfing, aber dann wieder beiseite gelegt habe. Ob das hier nun meine genaue Absicht war weiß ich gerade nicht mehr so genau

Wann werden die Konten eigentlich abgefragt? Gibts da eine bestimmte Uhrzeit am Tag?

Ja, derzeit täglich 1x, ab 12 Uhr (variiert jeden Tag ein wenig).
Ich nehme mir vor, das eventuell auf ein weiteres mal zu erhöhen (habe ich ja auch in den FAQ erwähnt, dass es max. 2x wird)

 

[Die-Fackel]

Kannst Du das auch manuell machen?
Mir kribelts zu wissen ob schon paar mitgemacht haben

 

[chrissel]

Kannst Du das auch manuell machen?
Mir kribelts zu wissen ob schon paar mitgemacht haben

Kann ich machen, ja. Vielleicht mache ich gleich ausnahmsweise mal die erste Zählung, damit man dann morgen bei der nächsten Zählung auch schon einen Graphen erkennen kann. Allerdings fehlt derzeit noch genau 1 Account, damit die Zählung überhaupt stattfinden kann
Setzt ja 20 Accounts voraus und wie viele sind somit eingetragen? Richtig: 19 derzeit!

Also ein paar Accounts sind schon dabei.. das werden aber hoffentlich noch deutlich mehr. Muss ja auch erst einmal anlaufen und sich herumsprechen..


EDIT: Erste Zählung erfolgreich gelaufen.

 

[Bububoomt]

Habe erstmal mein Klammaccount eingetrgen, aber da liegt selten was rum.

Bin ja mal gespannt wie sich das entwickelt.

 

[chrissel]

Ich habe nun doch noch umgestellt, dass es 2 Zählungen am Tag gibt.
Ab 0 Uhr sowie 12 Uhr (variiert auch jeden Tag ein wenig) werden nun die Lose gezählt.

 

[DaxDony]

Es gibt schon erste Werte.

ich denke man kann dies wesentlich schöner lösen, LC ist ja das beste beispiel da müsste man nur die Mediadaten auslesen xD

Auf den Teil mit dem PHP-Parser möchte ich jetzt mal nicht eingehen -p).
Der Sinn dieser Aktion ist es ja verlässliche Daten zu bekommen, einfach die Mediadaten auslesen bringt da nichts, ggf. könnten die Werte ja nicht stimmen.

Aufgrund des Fehlens eines reinen Statistik-PWs für EFs ist es nicht möglich die Losemenge sicher zu ermitteln.

Vielleicht sollten wir dieses Feature einfach mal bei Lukas anfragen.

 

[chrissel]

(Zitate kommen aus dem Thread der GLVA)

aua... das Script tut echt weh...
Wenn da einmal der PHP Parser aussetzt sind die EF IDs und PW öffentlich einsehbar sofern jemand die URL des Scriptes kennt... das ist keine feine Art.

Oder sehe ich das gerade falsch?

Sollte der PHP-Parser aussetzen auf einer Loseseite, werden dort auch die Passwörter sichtbar. Dann muss man dort nämlich nur die Konfigurationsdatei aufrufen und hat mindestens das MySQL-Passwort.. damit kommt man dann gut weiter.
Wenn man die URL des Losemenge-Scriptes kennt und der PHP-Parser setzt aus sieht man den Inhalt des Scriptes auch im Klartext und somit das Passwort, da hast du völlig recht. Das ist genau so schlimm dann, als wenn man direkt die Loseseite aufruft. Dafür muss dann der böse Mensch auch die URL zu dem Script wissen, die auf Losemenge auf jeden Fall verschlüsselt gespeichert wird, ob der Seiteninhaber die URL dann verbreitet oder nicht ist seine Sache.

Naja, hier werden unverschlüsselt EF-Daten rumgeschickt, aber das ist nicht unbedingt das Hauptproblem, sollte jedoch einmal sein Server geknackt werden, hat derjenige der es knackt sozusagen den Lotto-Jackpot gewonnen.

Die EF-Daten werden mittels POST an meinen Server direkt geschickt.
Wenn man EF-Abfragen im allgemeinen macht werden diese Daten an dem klamm-ExportForce-Server geschickt.
Man hat also in beiden Fällen das Risiko, dass jemand zwischen den Leitungen "sitzt" und mitliest.

Dann geht in das Thread und macht Verbesserungsvorschläge Ihr Experten.
Ich will das das Teil funktioniert und da auch mitgemacht wird.

Danke! Genau das wäre am besten, denn eure Fragen hier sind genau passend für den Thread.
Die Bedenken dürfen schließlich alle mitbekommen! Stehe ich durchgehend zu, dass man die ruhig haben darf.
Ich versuche nur diese Bedenken möglichst bedenkenlos zu machen und habe vor Veröffentlichung des Projektes mir einige Gedanken gemacht, wie man das alles so schafft und alles was mir dazu eingefallen ist umgesetzt.

Es gibt keine sichere Lösung, das ist das Problem daran. Entweder ist der EF mal von der Sicherheit von chrissel abhängig, oder die Menge wird manipulierbar. Aufgrund des Fehlens eines reinen Statistik-PWs für EFs ist es nicht möglich die Losemenge sicher zu ermitteln.

Du hast das Problem erfasst. Wobei es ein Statistik-PW für ExportForce-Accounts vermutlich nie geben wird...
Ich werde allerdings jeden weiteren Vorschlag umsetzen, um die Sicherheit weitergehend maximieren zu können.
Wer also Ideen hat -> raus damit!!

Irgendwie muss man doch die Datenbankeinträge mit einer Verschlüsselung speichern können die man nicht einfach dadurch knacken kann das man Zugang zum FTP bekommt und den Hash einfach runterläd.

Verschlüsselt sind ja alle relevanten Einträge (FAQ: Sicherheit und Datenspeicherung), allerdings liegt der Hash hierfür auf meinem Webserver und wäre über FTP Zugang erreichbar.
Das FTP-Passwort wird allerdings mit höchster Sorgfalt bei mir verwahrt. D.h. es hat Sonderzeichen, ist lang, wird in einer KeePass-DB gespeichert (diese ist durch ein kompliziertes PW verschlüsselt, welches ich nirgendwo notiert habe) und sonst nirgendwo. Ich bin da bei der Eingabe also nicht so faul und benutze Firefox zum Passwort speichern oder so.. das wäre ja fahrlässig

Es geht auch nicht um die Speicherung (die erfolgt hoffe ich garnicht), aber irgendwie muss chrissel mindestens einmal das PW im klar, pro Abfrage des Losestandes, bekommen und wenn jemand seinen Server knackt, dann kann dieser jemand die Abfrage durchführen und das PW einfach mitschreiben.
Wenn er das EF-Zeug speichern würde, wäre es noch schlimmer, aber das tut er (soweit ich richtig gelesen habe) nicht.

Welche Daten gespeichert werden, seht ihr ja in den FAQ.
Diese sind soweit es geht ohne Bezug untereinander gespeichert und Accountbezogene Losemengen oder EF-Passwörter werden auf keinen Fall gespeichert!


Guckt euch bitte nochmal alle die Alternative Möglichkeit an beim ExportForce eintragen!
Diese Möglichkeit benötigt KEINE Übermittlung des EF-Passwortes an meinen Server. Alle nötigen Operationen mit dem Passwort werden auf dem Server des Teilnehmers durchgeführt! Lediglich das Statistik-Passwort (des damit verbundenen klamm-Accounts) wird hierfür benötigt.

 

[ice-breaker]

Du könntest als Anfang ja wenigstens dafür sorgen, dass:

• die Passwörter in dem Script verschlüsselt sind
• die Übertragung verschlüsselt stattfindet

ich würde da empfehlen auf RSA zu setzen, jedes Script kennt deinen öffentlichen Schlüssel, die PWs werden im Script direkt nur mit dem öffentl. Schlüssel verschlüsselt gespeichert und Decodieren kannst nur du es mit dem privaten Schlüssel.

Du wolltest ja Verbesserungsvorschläge

Wenigstens etwas Sicherheit für das generell schon imho zu unsichere Verfahren, aber wie du sagtest, es ist eine Vertrauensfrage

 

[jgry]

Es gibt schon erste Werte.
Auf den Teil mit dem PHP-Parser möchte ich jetzt mal nicht eingehen -p).

Schade...

(Zitate kommen aus dem Thread der GLVA)



Sollte der PHP-Parser aussetzen auf einer Loseseite, werden dort auch die Passwörter sichtbar. Dann muss man dort nämlich nur die Konfigurationsdatei aufrufen und hat mindestens das MySQL-Passwort.. damit kommt man dann gut weiter.
Wenn man die URL des Losemenge-Scriptes kennt und der PHP-Parser setzt aus sieht man den Inhalt des Scriptes auch im Klartext und somit das Passwort, da hast du völlig recht.

Nein.
Man lege die Zugänge in einer PHP-Datei auserhalb des öffentlichen bereichs / in einem mit htaccess geschützen Bereich des Servers => Zugriff nur vom Localhost aus möglich.

Diese Datei wird in die öffentlichen Scripts die zugänglich sein müssen Includiert.
Fällt der Parser aus sieht man nur noch den Include Befehl, nicht aber die Daten. Den Dateinahmen zu kennen nützt einem auch nichts, wegen der Zugriffsbeschränkung auf den Bereich wo sich diese Datei findet.

Wer natürlich die Konfigurationsdatei nicht schützt, ist selber schuld, und sollte vielleicht mal drüber nachdenken ob es nicht besser wäre die eigene Seite dicht zu machen. Hart formuliert, aber so ist es nun mal.
Im öffentlichen Bereich hat diese nichts zu suchen.

Zwar ist ein Abschuss des PHP Parsers unwahrscheinlich, aber man sollte sowas bedenken, man weis ja nie was passiert...

Das ist genau so schlimm dann, als wenn man direkt die Loseseite aufruft. Dafür muss dann der böse Mensch auch die URL zu dem Script wissen, die auf Losemenge auf jeden Fall verschlüsselt gespeichert wird, ob der Seiteninhaber die URL dann verbreitet oder nicht ist seine Sache.

Ich denke bei einigen Seiten wir die URL dank dummheit auch zu erraten sein, da ich kaum glaube das sich jemand die mühe macht diese Dateien zu verstecken.

Aber als Tipp: Die Leute sollen das Script htaccess protecten so das nur deine Server IP auf dieses Verzeichnis Zugriff bekommt. Dies bringt schon mal einen guten Schutz gegen fremde aufrufe.

€:

Und das mit dem FTP: ich kann mir denken woher du das hast... nur ist es schon unwahrscheinlicher das jemand den FTP Knackt, anstatt das er durch eine ServerPanne (PHP Parser) oder durch einen Scriptfehler an die Daten kommt.

€²:

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

 

[DaxDony]

Du solltest ein Buch schreiben: "Sichere PHP-Applikationen entwickeln" und am Ende von jedem Kapitel schreibst du dann:

Wer natürlich die X nicht schützt, ist selber schuld, und sollte vielleicht mal drüber nachdenken ob es nicht besser wäre die eigene Seite dicht zu machen. Hart formuliert, aber so ist es nun mal.

 

[jgry]

Du solltest ein Buch schreiben: "Sichere PHP-Applikationen entwickeln" und am Ende von jedem Kapitel schreibst du dann:

was soll das werden? hast du immer noch ein Problem damit das ich meine Meinung dazu geäußert habe wie du Bankdaten gespeichert hast?
Lass es doch einfach sein, wenn du nichts Sinnvolles zur Sache beitragen kannst.

 

[chrissel]

Nein.
Man lege die Zugänge in einer PHP-Datei auserhalb des öffentlichen bereichs / in einem mit htaccess geschützen Bereich des Servers => Zugriff nur vom Localhost aus möglich.

Ja klar, ist mir bekannt.
Wird nur imho von den wenigstens Seiten hier auf klamm so gemacht (alleine die Scripts die im Umlauf sind bieten das glaube ich auch nicht ohne Änderungen an).
Und das der PHP-Parser versagt genau in dem Moment, in dem jemand die URL austestet ist finde ich sehr unwahrscheinlich.
Mal schauen ob ich dennoch die Passwörter in einer Konfigurationsdatei auslagere.

Aber als Tipp: Die Leute sollen das Script htaccess protecten so das nur deine Server IP auf dieses Verzeichnis Zugriff bekommt. Dies bringt schon mal einen guten Schutz gegen fremde aufrufe.

Das wäre eine Idee. Müsste ich nur schauen ob mein Script so etwas erlaubt. Also damit meine ich folgende URLs aufzurufen: https://usernameasswort@www.example.com/losemenge.php

Und das mit dem FTP: ich kann mir denken woher du das hast...

Woher ich was habe?

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ja, entweder viele Personen vertrauen einer (=mir) oder eine (=ich) vertraut vielen Personen.
Was wird wohl wahrscheinlicher sein? Das eine Person Mist baut oder das unter vielen Personen eine Mist baut?

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

So war es bei der damaligen Version von losemenge.de.
Allerdings vertraue ich ehrlich gesagt nicht allen Loseseitenbetreibern, dass diese mir richtige Daten übermitteln. Will einer mal die Losemenge hochtreiben übermittelt der einfach eine höhere Summe als er wirklich auf seinem EF-Account hat.
Und genau hierdurch kann ich am Ende nicht sagen, dass es wirklich mindestens so viele Lose gibt wie ich ermittelt habe. Man kann dann einfach keine verlässliche Zahl angeben..

 

[DaxDony]

Zum Thema verlässliche Daten, es ist halt eine Vertrauenssache, entweder die User Vertrauen auf die Sicherheit der Daten bei dir, oder du vertraust auf die Richtigkeit der Daten der User.

Ich fände es durchaus machbar wenn die Seiten ein eigenes Script betreiben das den EF Stand ausliest und man diesen Stand einfach nur einliest (bevor es wer Überliest: Ich spreche hier nicht von Userguthaben.).
So ist es in der Verantwortung des EFs inhaber wie sicher das Script ist, und nicht in deiner

Du hast das Prinzip von diesem Projekt absolut nicht verstanden. Es geht darum Daten zu bekommen, die 100% richtig sind. Das kann nur gewährleistet werden, wenn die Daten direkt über die Klamm-API ausgelesen werden, alles andere ist Schwachsinn.

Was meinst du wie viele Leute es geben wird, die es lustig finden werden einfach mal ein EF einzurichten, wo angeblich 1 bio Klammlose drauf sind.

 

[ice-breaker]

So, ich habe mir jetzt auch mal eine Stunde Gedanken gemacht.
Ich habe eine sichere Variante gefunden
Für irgendetwas muss Erfahrung doch gut sein. Es wundert mich, dass die noch niemand hatte...

kurzer Umriss:
Lukas bietet keine EF-Statistikfunktion an und die bisherigen Optionen sind für Seitenbetreiber nun nicht die optimalsten, jedoch gibt es doch Statistikpasswörter für normale Klamm-Konten, dies machen wir uns zu Nutze: Wenn der Losestand gemessen werden soll transferieren die Seitenbetreiber ihre Lose selbst auf ihren eigenen Klamm-Account von wo die Menge abgelesen werden kann und wenn die Menge erfasst wurde, können die Lose wieder zurück-transferiert werden.

lange technische Erklärung:
Mittels curl_multi_exec() wird parallel bei allen Seitenbetreibern ein Script aufgerufen, welches diesen mitteilt, dass sie ihre EF-Lose auf ihren Klamm-Account verschieben sollen (1). Diese Transaktion gilt nur für 30 Sekunden, d.h. dass die Seitenbetreiber selbst per Cron, wenn sie möchten, die Lose wieder nach der Zeitspanne abziehen können (Sicherheitsfunktion) oder erst wenn sie von LoseMenge.de die Nachricht erhalten, dass der Losestand fertig gemessen wurde.
Bekommt das LoseMenge.de nun von allen Seiten den Status zurück, dass sie fertig sind beginnt wiederum parallel (2) das Auslesen aller Klamm-Accounts mit den Statistikpasswörtern.
Ist dies fertig werden jetzt erst (3) alle Seitenbetreiber informiert, dass sie ihre Lose zurücktransferieren können, wenn sie dies selbst noch nicht durch die 30-Sekunden-Regel gemacht haben (unter der Annahme der Vorgang dauerte länger als 30s).
Nun ist das LoseMenge.de Script fertig und hat einen einigermaßen konsistenen Snapshot aller teilnehmenden Seiten ohne auch nur einmal in Besitz der Passwörter des EFs oder deren Lose zu sein.

Wer den Ablauf nun noch nicht ganz verstanden hat, kann sich das angehängte Sequenzdiagramm ansehen.



(1) dabei müssen natürlich nicht alle Lose verschoben werden, es kann ein Sicherheitspuffer aus dem EF für einen reibungslosen Betrieb bleiben. Dadurch hat man zwar nicht jedes Los in der Statistik, aber durch die breitere Akzeptanz des Verfahrens im Endeffekt eine viel höhere absolute Menge

(2) damit gleichzeitig stattfindende Transaktionen am wenigsten den Gesamtlosestand beeinflussen

(3) wenn dies nicht so wäre, und Seitenbetreiber direkt informiert werden würden, wenn sie ausgelesen wurden, könnten Sie ihre Lose auf einen anderen Account transferieren - mit dem sie kooperieren - in der Hoffnung, dass dessen Klamm-Account noch nicht ausgelesen wurde, dementsprechend würde die Losemenge doppelt gezählt werden.


@chrissel: du kannst mich auch gerne kontaktieren, falls noch Fragen sind

 

[jgry]

Ja klar, ist mir bekannt.
Wird nur imho von den wenigstens Seiten hier auf klamm so gemacht (alleine die Scripts die im Umlauf sind bieten das glaube ich auch nicht ohne Änderungen an).
Und das der PHP-Parser versagt genau in dem Moment, in dem jemand die URL austestet ist finde ich sehr unwahrscheinlich.

Unwahrscheinlich, aber nicht unmöglich, sowas ist einfach die feine art das man dies so macht. Nur weil es andere nicht machen, muss man selbst die Fehler ja nicht kopieren.

Das wäre eine Idee. Müsste ich nur schauen ob mein Script so etwas erlaubt. Also damit meine ich folgende URLs aufzurufen: https://usernameasswort@www.example.com/losemenge.php

Nein, das geht viel einfacher über die IP. Ich gehe mal davon aus das dein Server einen Statische IP hat...

# Datei zum Regeln von IP-Bereichen
Order deny,allow
Deny from all
Allow from A.B.C.D
Allow from 127.0.0.1

IPv6 Support ebenfalls möglich

Ersetze A.B.C.D mit deiner IP Adresse.
den localhost kann man sich in diesem Fall eigentlich auch sparen da dieser ja nicht benötigt wird.

Diese Datei mit dem Script in einen eigenen Unterordner und schon ist das Script gegen Fremd-aufrufe abgesichert. Zumal es sonst möglich wäre deinen Server zu "beschäftigen" mit diesem Script, mehr als die EF Idee braucht man ja nicht um eine Anfrage an deinen Server auszulösen.

Woher ich was habe?

Die Tatsache das du erwähnst das eine Verschlüsselung nutzlos ist wenn der FTP Server geknackt wird. Kommt mir so bekannt vor...

Ja, entweder viele Personen vertrauen einer (=mir) oder eine (=ich) vertraut vielen Personen.
Was wird wohl wahrscheinlicher sein? Das eine Person Mist baut oder das unter vielen Personen eine Mist baut?

Da könnte ich jetzt viele böse Beispiele bringen aber dann wird wieder Gepopelt da hab ich keine Lust zu.

Du kannst diese Möglichkeit ja auf Seiten begrenzen denen du vertraust.

Bzw auf EFs. Wie zum Beispiel den der GLVA? (ich kann zwar nicht für die GLVA Sprechen, aber ich denke es wäre wesentlich einfacher zu überzeugen wenn, und ich sehe keinen Grund warum die GLVA ihren EF-Stand manipulieren sollte.
Vorteil du hättest damit auch einen weiteren "größeren" (relativ) EF in der Liste

Dies würde sich auch positiv auf das Gesamtprojekt auswirken, misstrauen ist gut, aber es nimmt auch Möglichkeiten. Du sagst ja selbst, du vertraust nicht allen Seiten, dies beinhaltet das du Seiten/EF-Usern vertrauen würdest.
Diesen könntest du ja dieses Feature anbieten.

Du hast das Prinzip von diesem Projekt absolut nicht verstanden. Es geht darum Daten zu bekommen, die 100% richtig sind. Das kann nur gewährleistet werden, wenn die Daten direkt über die Klamm-API ausgelesen werden, alles andere ist Schwachsinn.

Was meinst du wie viele Leute es geben wird, die es lustig finden werden einfach mal ein EF einzurichten, wo angeblich 1 bio Klammlose drauf sind.

Siehe das, was über diesem Zitat steht...

 

[DaxDony]

Es wundert mich, dass die noch niemand hatte...

Schau mal hier:

Als Alternative gibt es noch ein Script, welches nur die freiliegenden Lose auf dem EF-Account erfassen kann (also keine im Tresor).
Dieses Script kann nur in Verbindung mit einem eingetragenen Klamm-Account genutzt werden und transferiert vor dem Auslesen alle Lose des EF-Accounts auf diesen und anschließend wieder zurück.
Hierdurch fallen allerdings pro Losezählung 3 ExportForce-Anfragen für jeden EF-Account an (Losestand auslesen, Lose einziehen, Lose zurückzahlen). Die einzigen Daten die das Script an Losemenge.de übermittelt sind alle eingetragenen EF-Accounts zum Abgleich mit den bei der ersten Methode eingetragenen EF-Accounts, keine EF-Passwörter!
Die Anmeldung geschieht über die normale Klamm-Account Anmeldung, hier muss einfach bei dem Punkt EF-Script der Link zu dem installierten Script eingetragen werden.
Sollte man sich bereits angemeldet haben mit seinem Klamm-Account kann man die Anmeldung mit dem EF-Script einfach wiederholen um dieses einzutragen.

 

[ice-breaker]

Neija das genau das damit ersichtlich ist, ziemlich doof beschrieben...
Zudem muss mein Ansatz nicht bei Tresorlosen halt machen.

Also wenn die Beschreibung so kacke ist und wirklich das gleiche beschreibt, sollte man die am besten aktualisieren und dies auch zur 1. Option machen, wer liest denn noch weiter, nachdem man ihm bei Option 1 sagt er soll sein EF-Passwort hergeben ...

 

[chrissel]

Neija das genau das damit ersichtlich ist, ziemlich doof beschrieben...
Zudem muss mein Ansatz nicht bei Tresorlosen halt machen.

Texte schreiben war noch nie so mein Ding, weiß ich, stehe ich zu

Vielen Dank erst einmal für dein Mühe und überaus ausführliche Darstellung (sollte echt für nahezu jeden verständlich sein, auch die Grafik gefällt mir )
Nuuur.. meine Alternative sollte genau so eine Möglichkeit darbieten.
Das Script auf dem Server des Teilnehmers wird aufgerufen, erhält den Befehl die Lose auf den klamm-Account zu transferieren. Anschließend werden diese mithilfe des Statistik-PWs ausgelesen und danach gibt es ein neuen Befehl diese wieder auf den EF zu transferieren.
Sollte doch so sein wie dein Ansatz? Nur, dass deiner im allgemeinen sicherlich schöner ausgearbeitet ist (gerade das mit den 30sec z.B. gibt es bei mir nicht; wenn keine Antwort kommt, dass die Lose zurück sollen, gehen diese auch nicht zurück).

und dies auch zur 1. Option machen

Ich habe immer noch ein Problem damit, dass zu viele Lose wahrscheinlich im Tresor liegen werden und diese werden bei der 1. Option mit beachtet, daher hatte ich diese auch als 1. Option da gelassen.

wer liest denn noch weiter, nachdem man ihm bei Option 1 sagt er soll sein EF-Passwort hergeben ...

Hm.. dafür steht da dick 'Alternative'? ^^


Aber wie hast du das mit den Tresorlosen vor? Wie kannst du die da mit einbeziehen? Aus dem Tresor kann man ja über die EF-API nichts entnehmen, nur Lose in den Tresor packen (wäre das anders würde der Tresor auch den Sinn verfehlen).
Die können doch nur manuell, also wenn der User sich auf ef.klamm.de einloggt usw, auf einen klamm-Account transferiert werden.


EDIT: ice-breaker, ich sitze gerade an der RSA Verschlüsslung und baue sonst noch ein paar Ideen mit in das EF-Script ein (die von jqry z.T.).
Was ich gefunden habe an RSA-Implementation für PHP ist die Klasse von www.torsten-keil.net; die PEAR-Implementation sieht finde ich nicht so schön aus der Beschreibung nach.