OAuth anstatt Losepasswort?

Glaub ich nicht... Laut Aufladeseite bekommt man für 5,00€ genau 50.000 Abfragen. In meiner Rechnungsliste hab ich eine Rechnung von 2005 mit dem gleichen Preis :think:

*edit*
Oder ist schon über 5 Jahre her :ugly:

Früher gab es für 5.- nen EF mit 500.000 Anfragen wobei da sogar täglich 10.000 frei waren (soweit ich mich errinere!)
Heute gibbet für 5.- nur noch nen EF mit 50.000 Anfragen und garkeine freien Anfragen mehr!

Aber wie gesagt! Das ist jetzt bereits echt ne ganze Weile her. Doch es gab damals wirklich ne Menge Diskusionen deshalb!
 
Zunächst war der Preis nur als "Hürde" gedacht, damit sich nicht jedes Kiddy nen Account macht. Als ich gemerkt habe, dass das auch tatsächliche Kosten verursacht, habe ich den Preis auf ein realistisches Niveau angeglichen.

Wer damals 500.000 für 5€ gekauft hat, durfte die 500.000 natürlich behalten.
Von daher ... ;)
 
Und wie wäre es mit einer Äußerung zu OAuth, wenn du eh schon im Thread bist?
Nebenbei könnte OAuth eventuell mehr einspielen als die Gebühren der EF-Anfragen, aus 50k Anfragen würden immerhin 50k Webseitenaufrufe auf Klamm für dich daraus werden.

Oh: 50k Bannereinblendungen auf Klamm würden ~50€ kosten, na das ist doch ein riesen Unterschied zu den 5€ für die EF-Transaktionen.
 
Zuletzt bearbeitet:
Und am Tag hast klamm ja ca. 24.000 EF Abfragen. Macht im Monat also knapp 720k Bannereinblendungen extra. :p

Am besten dann noch ein OAuth Ad einführen was speziell auf der Seite angezeigt wird (ich würde es buchen :ugly:).
 
Wegen 50k Einblendungen würde ich das nicht machen. Solange keiner auf die Werbung klickt, bringen mir die Einblendungen ja auch nix. ;)

Es wäre auf alle Fälle schon eine umfangreiche Änderung hier, auch von der ganzen Implementierung her (ich würde es wie immer alles selbst machen, nix Fertiges auseinadnerkrüppeln ...). Also WENN dann käme das zusammen mit ner komplett neuen EF-API (auf XML-Basis).

Ich verstehe das so, dass es ähnlich wie "Facebook-Connect" arbeitet. Man müsste es allerdings pro Transaktion zwingend machen und keine dauerhaften Tokens erlauben, sonst haben wir das gleiche Lose-PW-Klau-Speicher-Mißbrauch-Problem wieder. Das schränkt dann halt wiederum "Daueraufträge" etc. ein.

Aktuell empfinde ich den Gesamtaufwand im Vergleich zum tatsächlichen Nutzen als zu hoch. Mit sinnvollem Einsatz des Einweg-PW ist es in meinen Augen hinreichend sicher bzw. gibt es solche "ich buche mehr ab als ich anzeige"-Fälle kaum bis gar nicht - und genau die abzufangen, wäre ja der Hauptvorteil. Jede Seite/Person, die so arbeitet und gemeldet wird, wäre sofort weg vom Fenster.
 
ich würde es wie immer alles selbst machen, nix Fertiges auseinadnerkrüppeln ...
absolut sinnlose Einstellung, es gibt verdammt gute fertige Bibiliotheken, die deutlich besser sind, als wenn man sie selbst schreibt, immerhin haben da viele Leute mitgewirkt.
Mit ner fertigen Lib wäre der Aufwand nämlich nicht wirklich so groß.
 
Offtopic:

Sach ma Lukas, warst Du heute im Decathlon Ludwigshafen einkaufen?
Dachte ich hätte Dich da gesehen. Wollte schon nach nem Autogramm fragen *rofl*
 
Ne das war nich ich ...
Nach LU geht doch niemand freiwillig. :ugly:

Ich hab aber immer klamm-Fanartikel dabei falls mich jemand sieht. :p
 
Irgendwie schmeichelt es mir dass mein kleiner Vorschlag doch so hohe Wellen schlaegt dass sogar die hoechste Instanz seine Meinung dazu abgiebt :mrgreen:

Zunächst war der Preis nur als "Hürde" gedacht, damit sich nicht jedes Kiddy nen Account macht. Als ich gemerkt habe, dass das auch tatsächliche Kosten verursacht, habe ich den Preis auf ein realistisches Niveau angeglichen.

Kann ich durchaus verstehen, es erinnert mich irgendwie an Twitter. Deren Problem lag ja darin dass andere Applikationen das ganze Geld mit Werbung abgegriffen haben und sie, die die ganze Leistung erbringen, haben nichts davon.

Es wäre auf alle Fälle schon eine umfangreiche Änderung hier, auch von der ganzen Implementierung her (ich würde es wie immer alles selbst machen, nix Fertiges auseinadnerkrüppeln ...). Also WENN dann käme das zusammen mit ner komplett neuen EF-API (auf XML-Basis).

Ich verstehe das so, dass es ähnlich wie "Facebook-Connect" arbeitet. Man müsste es allerdings pro Transaktion zwingend machen und keine dauerhaften Tokens erlauben, sonst haben wir das gleiche Lose-PW-Klau-Speicher-Mißbrauch-Problem wieder. Das schränkt dann halt wiederum "Daueraufträge" etc. ein.

Oho, ein neues Interface? Is das ein versprechen oder eine Drohung? :D

Die aenderungen sind doch sehr tiefgreifend und im Endeffekt musst du die Vor- und Nachteile gegeneinander abwaegen.

Der ganze Kram "außenrum" ist trotzdem nicht wenig.
Es gehört ja auch etwas CI dazu und die Integration in sämtliche Lose-Abläufe.

Ich gehoer selber zu den Leuten die gerne alles selber machen moechten, einfach mal um die innereien zu sehen ^^

Was ich auch ganz interessant finde ist dass man modulare Zugangsrechte setzen kann, so dass man z.B. einigen Leuten die Rechte geben kann ein Kontostand einzusehen aber nichts dran zu veraendern, was so tolle Sachen ermoeglicht wie "Notare" zu beauftragen die Zahlungsfaehigkeit von Klammseiten zu bestaetigen :)arrow: keine Blasen die ploetzlich platzen koennen)
 
Zuletzt bearbeitet:
Was ich auch ganz interessant finde ist dass man modulare Zugangsrechte setzen kann, so dass man z.B. einigen Leuten die Rechte geben kann ein Kontostand einzusehen aber nichts dran zu veraendern, was so tolle Sachen ermoeglicht wie "Notare" zu beauftragen die Zahlungsfaehigkeit von Klammseiten zu bestaetigen :)arrow: keine Blasen die ploetzlich platzen koennen)
Das brauchst du dann keine Notare, sondern eine seriöse Loseseite könnte das Recht QueryEFLose an ANY geben, sodass jeder, den Losestand nachsehen kann. Bringt ja nix, wenn wieder nur ein Auserwählter (der dann sowieso mit dem Loseseitenbetreiber unter einer Decke steckt) da Zugang hat.
 
Das brauchst du dann keine Notare, sondern eine seriöse Loseseite könnte das Recht QueryEFLose an ANY geben, sodass jeder, den Losestand nachsehen kann. Bringt ja nix, wenn wieder nur ein Auserwählter (der dann sowieso mit dem Loseseitenbetreiber unter einer Decke steckt) da Zugang hat.

Stimmt, schlechtes Beispiel meinerseits. Aber mir fallen sicher noch szenarien ein fuer die eine schrittweise Authorization Freigabe Sinn macht. Denk nur an die Seiten bei denen der Tresor voll is, aber die Leute nicht auszahlen koennen weil der Account selber leer is, man koennte Mods erlauben Lose aus dem Tresor zu holen :)

Giebt sicher noch viele Moeglichkeiten wie das angewendet werden koennte.
 
Es gibt sicher viele Anwendungen, aber nimms mir nicht übel, wenn ich deine Versuche alle in der Luft zerreiß :mrgreen: :)
Denk nur an die Seiten bei denen der Tresor voll is, aber die Leute nicht auszahlen koennen weil der Account selber leer is, man koennte Mods erlauben Lose aus dem Tresor zu holen :)
Dieses Problem könnte jeder Loseseitenbetreiber ganz einfach lösen: Wenn ein User versucht auszuzahlen und der EF is leer, müsste er sich nur ne Mail/SMS (is doch hinzutage eh alles gekoppelt: geht ne Mail ein, klingelt das iPhone, oder? :ugly:) zustellen lassen, die gewünschte Auszahlung speichern und den User informieren, dass seine Auszahlung später bearbeitet wird.

Der Loseseitenbetreiber bucht dann ein paar Minuten später die Lose um und klickt einen Knopf in seinem ACP, dass die gescheiterten Auszahlungen dann selbstständig nachholt und die betroffenen User benachrichtigt, dass alles erledigt is.

Wie siehts in der Realität aus: Die große switch-Falle
PHP:
switch( $fehlerkot)
{
  case "1001":$feler = "EF dies";break;
 case 1002:
    $fehler = 'EF das'; 
        break;

/* .... */
      case '1010':
   $fehler = "keine lohse auf dem EF!!!"; break;
/* .... */
}
(Der Coding-Stil is absichtlich unter aller Sau, um es realistischer zu machen) schlägt zu und der User kriegt einfach nur den Satz hingeknallt, dass nix mehr da is und 2 Minuten später wird im Forum diskutiert, dass der Betreiber sich mit allen Lose nach Fidschi abgesetzt hat :ugly:

Fazit: Das Problem braucht keine neue API, sondern einfach nur kompetente Loseseitenbetreiber/-Programmierer.

(Nichtsdestotrotz bin ich aber natürlich nach wie vor für eine anständige API! :yes:)
 
Wie gesagt es kann viele Gruende fuer oder gegen jedes moegliche Szenario geben, aber ich denke man kann die API ausbauen (nicht dass sie jetzt schlecht is). In erster Linie geht es ja jetzt darum zu sehen dass sich an am EF selber wenig aendert, sondern man bekommt eher ein Paypal feeling: ich geh auf die Seite, erledige meine Sachen und wenn ich bezahlen will werde ich auf eine Seite weitergeleitet der ich vertraue um die Ueberweisung zu bestaetigen.

Im endeffekt wird's fuer den User nachvollziehbarer, die Seiten werden nicht so schnell unehrlichem Verhaltens angeklagt und die User haben volle Kontrolle ueber ihr Konto.

Ich hab' mir selber ueberlegt ob ich als Teil meiner Seite ein OAuth Frontend zu klamm.de bastel dass sozusagen die ganzen EF anfragen fuer andere Seiten uebernimmt, und ihnen eine OAuth API zur verfuegung stellt, aber da haben wir erstmal das chicken-egg Problem (niemand benutzt so einen service bis es nicht bekannt genug is und niemand wird darauf aufmerksam wenn's nieman benutzt) und ausserdem bezweifel ich dass es von den AGB von klamm.de erlaubt waere :ugly:
 
ausserdem bezweifel ich dass es von den AGB von klamm.de erlaubt waere :ugly:
Stell dir lieber die Frage wer haftet, wenn darüber Mist angestellt wird ;). Laut EF-AGB ist das nämlich uneingeschränkt der Besitzer des EFs, das wärst in dem Fall du. Du würdest also die gesamte Haftung für alles übernehmen, was deine Kunden da so anstellen.

Bestimmt nicht sonderlich sinnvoll ... ;).