Also doch der richtige Tyron :happy:
Wer verbreitet hier denn, dass du der falsche bist?
Alternativ @Luchs/NF: Was wäre mit "Login via Clonkspot"? 
Ich meine, ich kann auch beides anbieten - es ist immer toll als Plattform wenn Nutzer ohne große Registrierung dabei sein können.
Oh, ja wer kennt das nich…
Clonker A: "Los las uns das Pack XY übers Netz Zocken!!"
Clonker B: "Ja, warte ich lads mir schnell runter!"
-min. später
Clonker B: "So habst runtergeladen jetzt kanns losgehen!!"
Clonker A: "Alles klar… oh meine Version is auch nicht mehr aktuell warte ich muß mir erst die neue laden…"
-weiter min. später
Clonker A: "So musste erst die Packs Aktualiesieren und lade jetzt das Pack XY neu herunter."
Clonker B: "Ach egal laß uns was anderes zocken…"
Mit so einem Pack-Verwalter wäre so etwas nie wieder ein Problem und mann müste auch nicht (falls nötig) all die kleinen Packs die man für manche Karten braucht zusammen suchen.
…von daher SUPER IDEE!!!
Hm, dann auch via OAuth oder wie stellst du dir das vor? Muss ich mal gucken, aber das dürfte ja theoretisch nicht so schwer sein…
OAuth ist cool 
Hab grad mal die "About" Seite von OAuth durchgelesen. Ist das sinnvoll als Single-Sign-On Lösung? Die About-Seite sagt mir, dass es dafür nicht gemacht ist? confus
Es ist etwas kompliziert, gerade im Vergleich auch mit OpenID - bei OAuth vertraue ich (Lorry) dem Provider (Clonkspot) mir die "richtigen" Benutzer-Details (vor allem die richtiger User-ID) mitzugeben und die nicht zu fälschen. Im Gegensatz zu OpenID, wo ich als Nutzer den Provider (Open-ID-Punkt) selbst wählen kann, und Lorry dem Nutzer selbst überlässt, seine Idendität zu bestätigen. Kurz gefasst:
OpenID: Ich als Nutzer authentifiziere mich bei meinem eigenen Provider, und Lorry weiß dass ich es bin, weil es mein Provider ist.
OAuth: Ich als Nutzer gebe dem Provider die Erlaubnis, meine Provider-ID an Lorry weiterzugeben, und Lorry weiß dass ich es bin, weil es meine ID ist.
Im ursprünglichen Sinne sollte man eigentlich keine Authentifizierung mit OAuth machen - es ist dafür gedacht, dass ich z.B. meinen Twitter-/Facebook-Account verknüpfen könnte und dann automatisch irgendwelche Posts rausschicke, ohne mein Passwort einzugeben. Da du aber in beiden Fällen zum Provider (bei OpenID selbstgewählt, bei OAuth vorgegeben) weitergeleitet wirst und in beiden Fällen eine eindeutige Zuordnung garantiert werden kann - sofern du als Administrator vertraust, dass dich dein OAuth-Provider (sei es Google, Facebook, Clonkspot) nicht hintergeht und sich jemand als dich ausgibt - reicht mir das als Identifizierung. Außerdem ist es ja nicht Pflicht einen Provider zu nutzen oder zu verknüpfen.
[Englischer Wiki-Aufschrieb zur Authentifizierung mit OAuth]
>OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are.
Genau, wenn sich das irgendwie in die MW-Forum-Authentifizierung integrieren lässt. Das wäre aber auf jeden Fall etwas das noch down-the-road gemacht werden könnte (Lorry nutzt atm eine OAuth2-Library).
Ich glaub eher eine Unterkategorie von EKE Szenarien, weil sich die Kategorie von Projekt zu Projekt nicht unterscheidet
>Wer verbreitet hier denn, dass du der falsche bist?
k.A. Die lange inaktivität hat mich halt zum Mythos gemacht XD
Stand der letzten Wochen: Entwicklung lief bis vor einer Woche ganz gut, dank alas Konzepten habe ich auch fast alle Workflows fertig designt und auch das Uploadsystem (wenn auch als Prototyp) größtenteils implementiert (ich nutze Resumable.js, die ohne FTP den Upload von großen Dateien über den Browser ermöglicht, selbst bei instabilem Internet). Aktuell mache ich mir etwas Sorgen um die Sicherheit der Plattform, ich nutze eine selbstentwickelte Lösung die zwar in meinen Augen ziemlich sicher gebaut ist (XSS-Filterung, Prepared Statements, CSRF-Tokens…), aber bin noch nicht ganz davon überzeugt.
Speziell die letzten Tage kamen auch Bedenken von Tyron und ArneB im CF auf, die ihr CCF/CCAN respektive nicht vollständig für Nutzer öffnen wollen, da sie kein echtes Sicherheitskonzept haben. Ich traue den beiden eine Menge zu, und bin daher etwas verunsichert, was die Stabilität von Lorry angeht. Ich versuche zwar immer meinen Code möglichst sicher zu entwerfen und auf dem aktuellen Stand von Sicherheitsproblemen im Web zu bleiben, aber hatte auch noch nie jemanden der wirklich versucht hat eine Website/ein Tool von mir anzugreifen.
Ich überlege mir gerade stark, das Backend auf Symfony zu portieren - zum Einen, weil ich mich bisher nur oberflächlich damit beschäftigt habe und gerne mehr darüber lernen möchte, zum anderen weil es eine bekannte, stabile und sichere Plattform ist. Lorry nutzt außerdem bereits beispielsweise eine abgekapselte Version der Templating-Engine von Symfony (Twig). Das Portieren wird zwar seine Zeit dauern, aber danach habe ich eine stabile, sichere Plattform die auch mit einer größeren Community gut zurecht kommt, die auch dann hoffentlich gut erweiterbar ist. Hm, ich überlege mir das noch gut.
Ich glaube ganz konkret gab es bisher doch nur ein Community-Mitglied was nachweislich das CC und den CCAN gehackt hat. Würd ich mich jetzt nicht verrückt machen deswegen.
Lieber B_E, ich denke auch, dass ein portieren zu Symfony dich nicht unbedingt deinem Ziel näher bringt.
Ich habe inzwischen etwa 12 Jahre Erfahrungen mit Webapplikationen und in meinem Studium mehrere Vorlesungen zu Security abgeschlossen. Von daher kann ich dir glaub ich behilflich sein. Ich habe deinen Code etwas studiert, hier ein paar Tipps:
- Alle Dateninputs (GET, POST, REQUEST, COOKIE, etc.) per Default filtern. Ich habe mir z.b. in den neuesten Projekten eine Input-Klasse programmiert die GPRC daten in private vars speichert, unset($_GET) usw. ausführt und dann nur noch gefilteren zugriff zu GPRC-Daten erlaubt: $input->whitelistget("userid" => "integer"); $userid = $input->get("userid")
- Mittels .htaccess per Default Zugriff zu allen Verzeichnissen/Dateien verbieten. Zugriff zu einzelnen Verzeichnissen explizit erlauben.
- Alle Ausgabedaten escapen, in Smarty geht das mittels {$data|escape} - noch besser: Alle Ausgabedaten per default escapen und ausnahmen explizit erlauben.
- Bei allen Seiten per Default mit CSRF Tokens schützen, dann explizite Ausnahmen erlauben
Mit diesen Punkten zusätzlich, hast du meiner Meinung nach ein sehr sicheres System. Wenn du alles per Default sicherst, hast du im Fehlerfall keine Sicherheitslücke sondern nur eine zu hoch geschützte Komponente.
Als ich den CC/CCF programmiert hatte, hatte ich "insecurity by default" - d.h. alle sicherheitsbeschränkungen explizit angegeben. Damit sind viele Sicherheitslücken entstanden weil irgendwo ein filtern vergessen wurde - trotzdem gibts den CC/CCF bis heute noch
Sei also nicht entmutigt! Du programmierst jetzt schon mit einem viel besseren Sicherheitskonzept als ich damals hatte!
Wenn du dann auch noch ein starkes hashing für die Benutzerpasswörter verwendest und regelmäßig backups machst, dann kann auch im Falle eines Hackerangriffs nicht viel Schaden entstehen.
[Edit:] Noch ein Tipp: Lass die Software Netsparker Community Edition über deine Website scannen. die war extrem hilfreich bei mir - hat viele Lücken aufgedeckt von der ich noch nichts wusste.
Gab es eigentlich einen nachvollziehbaren Grund warum er das gemacht hat? Der hießt doch RussianBear oder irgendwas mit Bär wenn ich mich nicht Irre :D?
Yay, ein Statusupdate, Lorry ist nicht inaktiv! \o/
GhostBear.
Spaß an der Freude und Langeweile wohl.
Genaugenommen gab es mehrere, aber die meisten in der Community waren freundlich genug mir den Fehler zu melden und nicht auszunutzen.
Hat er nicht danach den jeweiligen Admins von der Sicherheitslücke berichtet oder so?
Nachdem er die Nutzerdaten kopiert hatte? 