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

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).
ja dann schon


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.
besser als wenn nur 1 EF teilnimmt oder? ;)
Wenn du die Variante noch ausbaust und es kostenlos als FWX und VMS Plugin bereitstellst, finden sich bestimmt noch einige mehr die da mitmachen würden.


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.
ich hab schon ewig nimmer mit dem EF gearbeitet, wenn das nicht geht, dann ignorier es :biggrin:


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.
nimm die Variante, die am sichersten ist, also folgende Bedingung erfüllt:
  • Sie kann RSA-Zertifikate laden (sehr wichtig !!! die Schlüsselerzeugung ist sehr komplex, mach das mit einem Linux)
  • sie verschlüselt sicher (sichere Blockchiffre) :mrgreen:
Ich würde ja zu Zend_Crypt_RSA raten, ich hab mir die Implementation noch nicht angesehen, aber da haben denke ich viele drübergeschaut.

Edit: Zend_Crypt_RSA benötigt OpenSSL, Torsen Keils Implementierung hingegen nicht (erfüllt aber auch nicht alle Sicherheitseigenschaften) und die Pear-Implementierung kann gar nicht verschlüsseln, bleibt dir also nur die Implementierung von Keil-Implementierung
 
Zuletzt bearbeitet:
noch ein kleiner Hinweis zur Idee mit dem Hin und Herschieben der Lose.
Hier ist eine Auswertung um 0 Uhr eher ungünstig, um 0:10 werden einige den Dauerauftrag zur Sicherung der Lose in den Tresor aktiv haben. Daher kann es dort zu unschönen konflikten kommen, wenn die Buchungen etwas verzögert ablaufen und dann nicht zurückgebucht werden kann.

Ich weiß nicht ob du auch schon dran gedacht hast, aber es sollten auch nur die Lose zurück Übertragen werden, die auch vorher auf dem Klamm Account vorhanden waren, nicht das jemand zur Zeit der Zählung auf dem Klamm Account Lose offen liegen hat, und die dann nach der Zählung ebenfalls auf den EF geflossen sind.
 
Die genannte Alternative mag schön und gut sein, aber ich HOFFE das die meisten Lose tatsächlich im EF-Tresor rumliegen und dann wird es schlicht und ergreifend schon nix mehr.
Die Seitenbetreiber mit denen ich im Kontakt bin, als auch ich selbst haben zumindest die meisten Lose einfach im Tresor und nur einen gewissen, meist sehr kleinen Teil, für Auszahlungen frei rumliegen.
 
besser als wenn nur 1 EF teilnimmt oder? ;)
Wenn du die Variante noch ausbaust und es kostenlos als FWX und VMS Plugin bereitstellst, finden sich bestimmt noch einige mehr die da mitmachen würden.

Die Idee mit dem Plugin hört sich gut an.
Muss ich mal schauen, ob sich so etwas einrichten lässt. Habe lange nichts mehr mit FWX und VMS gemacht.


bleibt dir also nur die Implementierung von Keil-Implementierung

Diese habe ich auch soeben eingebaut. In meiner Testumgebung hat alles funktioniert, ich hoffe bei der nächsten Zählung gibt es damit keine Komplikationen.
Zusätzlich habe ich ein kleines Installationsscript geschrieben, welches die EF-Daten direkt verschlüsselt in die Konfigurationsdatei speichert. Der Speicherort dieser Datei kann auch freigewählt werden.

noch ein kleiner Hinweis zur Idee mit dem Hin und Herschieben der Lose.
Hier ist eine Auswertung um 0 Uhr eher ungünstig, um 0:10 werden einige den Dauerauftrag zur Sicherung der Lose in den Tresor aktiv haben. Daher kann es dort zu unschönen konflikten kommen, wenn die Buchungen etwas verzögert ablaufen und dann nicht zurückgebucht werden kann.

Puh, stimmt. So etwas gibt es ja auch noch. Ich schau mir das noch genauer an und verschiebe ggf. die Zählung um ein paar Minuten.

Ich weiß nicht ob du auch schon dran gedacht hast, aber es sollten auch nur die Lose zurück Übertragen werden, die auch vorher auf dem Klamm Account vorhanden waren, nicht das jemand zur Zeit der Zählung auf dem Klamm Account Lose offen liegen hat, und die dann nach der Zählung ebenfalls auf den EF geflossen sind.

Es gibt eine 'temp'-Datei bei dieser Methode in welcher der Losestand des EF-Accounts gespeichert wird. Somit werden auch nur die Lose zurück gebucht, die vorher auf dem EF waren.
 
Puh, stimmt. So etwas gibt es ja auch noch. Ich schau mir das noch genauer an und verschiebe ggf. die Zählung um ein paar Minuten.

nicht nur um ein paar Minuten, es wäre generell am sinnvollsten wenn du alle Ausleseoperationen auf einen Zeitpunkt verschiebst, an dem möglichst wenig Aktivität herrscht, so dass z.B. Transaktionen die sich mit deinem Script bei Nutzern überschneiden zu keiner Doppel-Zählung führen.
Um 3 Uhr morgens ist da das perfekte Zeitfenster ;)
 
Hi,

hau mal Flooky von Zockhaus.de an wegen dem Fwx Addon.

Ich habe mir das alles durchgelesen und bin nicht bereit irgendwas auf meinem Server zu installieren geschweige mein Ef passwort an dritte weiter zugeben.

Habe daraufhin überlegt 80% der Lose in meinen Klammaccount (tresor) zu verlegen und dadurch eher zu helfen.

Es gibt zumindest beim FWX die möglichkeit (adminmenü) die alle Informationen zum EF anzeigt.



Diese Info wird bei jeder Ein- oder Auszahlung im FWX gespeichert.

Wenn man also nur diese Daten ausliest könnte man schon enorm viel Auslesen und ich denke auch das viel mehr mitmachen, da man einfach keine Daten rausgeben muss (pw etc).

Einen Haken gibt es: Wenn jemand manuell in seinem Ef rumfummelt (auszahlt, einzahlt) dann wird im Admin erst bei einer erneuten EInzahlung/Auszahlung vom Fwx neu ausgelesen.

MfG

traxtrax
 
Interessante Aktion.
Bin auch mal dabei und hoffe das da paar Lose zusammen kommen...

Gleich müsste auch wieder ne neue Auszählung stattfinden oder?
 
Ich habe soeben die Methode zum EF-Kontostand auslesen entfernt, bei der das Passwort an Losemenge.de übermittelt wird.

Nun gibt es nur noch die sichere Möglichkeit, bei der alle Passwörter auf den Servern der Teilnehmer bleiben, außer natürlich das Statistik-Passwort :p
Vielen Dank auch an ice-breaker, der mir durch seinen Post weitere Verbesserungen an dieser Methodik gezeigt hat, diese habe ich nun auch alle soweit umgesetzt.
Somit steht nun für die EF-User eine sehr sichere Methode zur Verfügung, um an der Berechnung einer Mindestlosemenge dran teilzunehmen!

Für das Script habe ich ein sehr simples Installationsscript angelegt mit dem man das Script für bis zu 5 EF-Accounts erzeugen kann. Möchte man mehr eintragen, so kann man das direkt über Bearbeitung der Konfigurationsdatei tun (erfordert daher geringe PHP-Kenntnisse).

Um Engpässen bei der Auszahlung entgegenzuwirken kann man auch einen Puffer einstellen, d.h. ein prozentualer Wert (Standardmäßig 3 %) bleibt auf dem EF-Account erhalten.
Ich würde mich aber freuen, wenn dieser Puffer bei den meisten auf 0 % gesetzt wird, denn diese Lose fehlen in der Berechnung.
Denkt dran: Das Script läuft Nachts zwischen 3 und 4 Uhr, da wird die Chance, dass genau in den paar Sekunden in denen das Script läuft jemand von eurem Konto auszahlen möchte sehr gering sein!


(Ich hoffe ich habe auf der Seite alle Texte zur neuen Methode hin aktualisiert und verweise auf die alte Methode entfernt, falls nicht: kurz melden)
 
Zum zweiten mal angemeldet.

Wurde das gestern oder so resettet ?
naja wie auch immer bin wieder dabei.
ps meinen account kannst du gerne zu 100% Updaten sonnst kommt das ja nie hoch sollten dan heute abend so 2 MRD mehr sein
 
Zum zweiten mal angemeldet.

Wurde das gestern oder so resettet ?

Nein, allerdings könnt ihr euch so oft "anmelden" wie ihr wollt, ihr aktualisiert lediglich damit eure Angaben. Bzw könntet aktualisieren ob ihr das EF-Script nutzt oder nicht.

ps meinen account kannst du gerne zu 100% Updaten sonnst kommt das ja nie hoch sollten dan heute abend so 2 MRD mehr sein

Kann ich leider nicht machen, ich weiß nicht welcher Eintrag in der Datenbank zu deinem Account gehört ;)
Dafür müsste ich deine klamm-ID nochmal verschlüsseln lassen damit ich das herausfinde.. hmm.. kann ich gleich wohl eben machen ;)
 
Nein, allerdings könnt ihr euch so oft "anmelden" wie ihr wollt, ihr aktualisiert lediglich damit eure Angaben. Bzw könntet aktualisieren ob ihr das EF-Script nutzt oder nicht.

achso ok
Nu wie gesagt habe mich gestern Morgen oder vorgestern Abend angemeldet,
dann mich Heute gewundert warum die Anzeige so gering ist.
Mich dann nochmal angemeldet kam die Rückmeldung erfolgreich eingetragen, oder so ähnlich.
Dann zum Test nochmal angemeldet dann kam Daten aktualisiert.
Darum dachte ich ev. gelöscht.
Naja spielt ja keine rolle.

MFG
LKTechnik
 
dann mich Heute gewundert warum die Anzeige so gering ist.

Ja, hat mich auch gewundert. Habe aber mittlerweile gefunden, warum der da meinte weniger anzeigen zu müssen. Heute Nacht sollte die Zahl um einiges ansteigen ;) [sofern denn im Produktiveinsatz das neue Auslesungssystem läuft...]
 
kann es sein das dein Auswertungsscript einen Fehler macht wenn es die History erstellt?
Im Diagramm finden sich für ein und die selbe Uhrzeit immer genau 2 verschiedene Einträge. Dadurch ergibt sich zwar eine nette "Treppe", aber es sieht halt komisch aus wenn um die selbe Uhrzeit zwei verschiedene Mengen ermittelt wurden.

Wie sieht es nun eigentlich mit der zweiten Methode aus, ich hoffe doch das auch dieses Script per htaccess bei den EF-Usern geschützt ist. Es liegt zwar nicht in deiner Verantwortung, aber es wäre sehr gut wenn du sie ausdrücklich darauf hinweisen würdest.
 
kann es sein das dein Auswertungsscript einen Fehler macht wenn es die History erstellt?
Im Diagramm finden sich für ein und die selbe Uhrzeit immer genau 2 verschiedene Einträge. Dadurch ergibt sich zwar eine nette "Treppe", aber es sieht halt komisch aus wenn um die selbe Uhrzeit zwei verschiedene Mengen ermittelt wurden.

Ich habe auf Hinweis von ice-breaker ein Stufendiagramm oder wie man so etwas auch immer nennt eingestellt.
Sein Einwand war nämlich, dass man ja keinen linearen Verlauf hat beim auslesen, somit war die vorherige Diagrammart (normales Liniendiagramm) nicht wirklich dafür da die Realität wiederzuspiegeln.
Genau so hat er es ja auch auf Losepreis.de eingebaut und ich stimme seinem Einwand voll zu ;)
Das man vom unteren Teil der Treppe einen Punkt hat liegt am jQuery-Flot, ich war nun ehrlich gesagt zu faul diesen Punkt irgendwie zu entfernen, das wird nun mal standardmäßig da so gemacht bei diesem Diagrammtyp ;)

Wie sieht es nun eigentlich mit der zweiten Methode aus, ich hoffe doch das auch dieses Script per htaccess bei den EF-Usern geschützt ist. Es liegt zwar nicht in deiner Verantwortung, aber es wäre sehr gut wenn du sie ausdrücklich darauf hinweisen würdest.

Nein, die Installation generiert keine .htaccess.
 
Wie sieht es nun eigentlich mit der zweiten Methode aus, ich hoffe doch das auch dieses Script per htaccess bei den EF-Usern geschützt ist. Es liegt zwar nicht in deiner Verantwortung, aber es wäre sehr gut wenn du sie ausdrücklich darauf hinweisen würdest.

Oh man. Du willst ein Script vor HTTP-Anfragen schützen, dass über HTTP aufgerufen wird? Wtf? :wall: