• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

sqStorage Webbasierte Mini-Lagerverwaltung

braegler

NGBler

Registriert
14 Juli 2013
Beiträge
878
Die API (also wirklich die api.php) überprüft bereits von selbst ob die Registrierung aktiv ist und ob ein gültiger Login vorliegt
Ist sie inaktive, kann voll* auf die API zugegriffen werden
*(Voll bedeutet auf die Tabellen: customfields,fielddata,headCategories,images,items,storages,subCategories)

Ist die Registrierung aktiv wird ohne gültigen Login kein Zugriff zugelassen.
Login bedeutet: Entweder
-eine gültige Session beim Zugriff über z.B. AJAX
-Login über einen expliziten Login mit Username und Password call gegen die API

Liegt ein gültiger Login vor, können Gäste (usergruppe 2) nur lesen (GET), aber nicht schreiben (PUSH/PUT/DELETE/PATCH)
In den Zeilen 12387 bis 12391 der api.php ( https://github.com/schnoog/sqstorage/blob/master/api.php ) wird der Zugriff für Usergruppe 2 geregelt
Nur die operationen "list" und "read" ( beides GETs]) is erlaubt. Für alle anderen Operationen wird mit "return false" der Zugriff verweigert.

PHP:
if($ug == 2){
      if($operation  == "list") return true;
      if($operation  == "read") return true;
      return false;
}


Btw: Die API ist ein drop-in. Also eine einzelne Datei die keinerlei sonstiger Abhängigkeiten hat (ausser natürlich ne vorhandene dba.php)
Wenn Du Sie Dir aus meinen Branch (GitHub - schnoog/sqstorage: A easy to use and quick way to organize your inventory, storages and storage areas) runterlädst und ins Hauptverzeicnnis schmeisst, kannst Du schon drauf loslegen (htaccess-Eintrag ist nicht notwendig, musst dann halt nur "api.php" anstatt "api" aufrufen)


sollte Dir dann alle vorhandenen Lagerplätze anzeigen.
(Ich hab Download für mich entdeckt um damit auf die API einzuballern. GET requests kann man natürlich auch einfach im Browser aufrufen.
 

theSplit

1998
Teammitglied

Registriert
3 Aug. 2014
Beiträge
28.008
  • Thread Starter Thread Starter
  • #182
Hm, okay, das klingt ja schon ganz gut.

Was mir nicht so gut gefällt:
- Login über einen expliziten Login mit Username und Password call gegen die API

[...] runterlädst und ins Hauptverzeicnnis schmeisst, kannst Du schon drauf loslegen..

Ist da irgend ein Sicherheitsmechanismus in der API hinter? Gegen Flooding, Bruteforce oder gar Ddos?
Wäre es möglich so etwas zu integrieren? Zum Beispiel dass gegen eine Tabelle in der DB überprüft wird ob bereits ein Zugriff vorliegt, wann, und wie oft Fehllogins gemacht worden sind - oder ähnliches?

Vielleicht sollte auch ein genereller API-User in der Datenbank angelegt werden, das dieser von anderen Accounts isoliert wird und entsprechend Settings für die API Usage geregelt werden können?
Heißt der Admin kann entscheiden "ob die API aktiviert wird", kann den Usernamen setzen und ein Passwort und kann vielleicht sogar regeln was über die API gemacht werden kann?

Ich will dir die Idee nicht austreiben, sind aber 2-3 Gedanken dazu.
 

braegler

NGBler

Registriert
14 Juli 2013
Beiträge
878
Sicherheitsmechanismus gibt es da bisher keinen (ist aber auch login.php auch nicht implementiert).
In Sachen Zugriffsschutz steht sie der aktuellen "WebApp "in Nichts nach.

Ab Zeile 8108
Code:
if ($path == 'login') {
der api.php folgt der Login gegen die Datenbank.
Das ist beliebig erweiterbar und könnte man dann im Zuge des Einbaus eines Rate-Limiter in der login.php mitziehen.
Das braucht ja ein neues DB Feld (oder Tabelle), dann kann man das in einer DB Migration unterbringen.

Erstell doch auf github einen Development branch. Dann den PR dort rein mergen (hat ja keine Konflikte).
Den kannst Du dann relativ einfach in den Master mergen wenn alles läuft wie gewünscht (und den "aktuellen" Dev Stand kann man damit einfach abgleichen.
 
Oben