Problem mit Passwort-Schutz

udoz · 10. April 2014

Moin,

Ich möchte temporär ausgewählte Pakete/Paketversionen zwecks diverser Tests vor den Nutzern verstecken bzw. diesen den Zugriff zumindest verweigern. Nach Hinweis bei WL habe ich im pserver-Verzeichnis, in dem packages und die anderen Dateien (config.js, app.coffee...) liegen, folgende auth.json erstellt:

Code

{
	"users": {
		"Administrator": {
		"passwd": "$2a$08$AoDKKg1ptSKcT0y.YCudrure4VBWK2PLkPtN.GQ4EEGW5q5th032q",
		"groups": [ "Admin" ],
		"packages": {
			}
		},
	},
	"groups": {
		"Admin": {
			"*": "*"
		}
	},
	"packages": {
		"com.uz.wbb.absence": "*",
		"com.uz.wbb.box.topPoster": "*",
		"com.uz.wbb.thread.similar": "*",
		"com.uz.wbb.welcome": "*",
		"com.uz.wcf.absence": "*",
		"com.uz.wcf.birthday.box": "*",
		"com.uz.wcf.birthday.display": "*",
		"com.uz.wcf.box.mostActive": "*",
		"com.uz.wcf.box.mostLiked": "*",
		"com.uz.wcf.invitation": "*",
		"com.uz.wcf.nofollow": "*",
		"com.uz.wcf.notification.preset": "*",
		"com.uz.wcf.report.wbb": "*","
		"com.uz.wcf.welcome": "*",
		"com.uz.wbb.welcome": "*",
		"com.uz.wcf.bot": "$v >= 1.0.0 && $v < 1.1.0",
		"com.uz.wcf.bot.wbb": "$v >= 1.0.0 && $v < 1.1.0",
		"com.uz.wcf.bot.news": "$v >= 1.0.0 && $v < 1.1.0",
		"com.uz.wcf.bot.blog": "$v >= 1.0.0 && $v < 1.1.0",
		"com.uz.wcf.bot.application": "$v >= 1.0.0 && $v < 1.1.0"		
	}
}

Alles anzeigen

Idee dahinter: untere Pakete frei verfügbar, Versionen ab 1.1.0 (...bot...) nur mit Admin/Passwort.
Folge ist ein Fehlermeldung, die auch nicht verschwindet, wenn die auth.json gelöscht und der server neu gestartet wird:

Code

PHP notice in file C:\xampp\htdocs\wbb\wcf\lib\system\package\PackageInstallationScheduler.class.php (227): Undefined offset: 2


Stacktrace:


#0
 
C:\xampp\htdocs\wbb\wcf\lib\system\package\PackageInstallationScheduler.class.php(227):
 wcf\system\WCF::handleError(8, 'Undefined offse...', 
'C:\xampp\htdocs...', 227, Array)


#1 
C:\xampp\htdocs\wbb\wcf\lib\system\package\PackageInstallationScheduler.class.php(123):
 
wcf\system\package\PackageInstallationScheduler->downloadPackage('com.uz.wbb.abse...',
 Array)


#2 
C:\xampp\htdocs\wbb\wcf\lib\system\package\PackageInstallationScheduler.class.php(97):
 
wcf\system\package\PackageInstallationScheduler->installPackage('com.uz.wbb.abse...',
 '1.0.2')


#3 
C:\xampp\htdocs\wbb\wcf\lib\system\package\PackageInstallationScheduler.class.php(64):
 
wcf\system\package\PackageInstallationScheduler->tryToInstallPackage('com.uz.wbb.abse...',
 '1.0.2', true)


#4 
C:\xampp\htdocs\wbb\wcf\lib\data\package\update\PackageUpdateAction.class.php(497):
 
wcf\system\package\PackageInstallationScheduler->buildPackageInstallationStack()


#5 
C:\xampp\htdocs\wbb\wcf\lib\data\package\update\PackageUpdateAction.class.php(480):
 wcf\data\package\update\PackageUpdateAction->createQueue('install')


#6 [internal function]: wcf\data\package\update\PackageUpdateAction->prepareInstallation()


#7 C:\xampp\htdocs\wbb\wcf\lib\data\AbstractDatabaseObjectAction.class.php(182): call_user_func(Array)


#8 C:\xampp\htdocs\wbb\wcf\lib\action\AJAXProxyAction.class.php(76): wcf\data\AbstractDatabaseObjectAction->executeAction()


#9 C:\xampp\htdocs\wbb\wcf\lib\action\AJAXInvokeAction.class.php(96): wcf\action\AJAXProxyAction->invoke()


#10 C:\xampp\htdocs\wbb\wcf\lib\action\AbstractAction.class.php(49): wcf\action\AJAXInvokeAction->execute()


#11 C:\xampp\htdocs\wbb\wcf\lib\action\AJAXInvokeAction.class.php(63): wcf\action\AbstractAction->__run()


#12 C:\xampp\htdocs\wbb\wcf\lib\system\request\Request.class.php(58): wcf\action\AJAXInvokeAction->__run()


#13 C:\xampp\htdocs\wbb\wcf\lib\system\request\RequestHandler.class.php(108): wcf\system\request\Request->execute()


#14 C:\xampp\htdocs\wbb\acp\index.php(10): wcf\system\request\RequestHandler->handle('wbb', true)


#15 {main}

Alles anzeigen

Wo liegt das Problem?
Ist die o.a. Vorgehensweise mit der auth.json überhaupt korrekt?

**Tim** · 10. April 2014

Hallo,

zuerst: Die auth.json gehört in den packages-Ordner, da wo auch die example liegt. Weiterhin solltest du zuerst versuchen das Paket im Browser herunterzuladen, da du so eventuelle Fehlermeldungen leichter mitbekommst.

Hast du evtl den Paketserver im WCF gelöscht? Die Fehlermeldung vom WCF deutet auf irgendwie so etwas hin.

udoz · 10. April 2014

Zitat von Tim

zuerst: Die auth.json gehört in den packages-Ordner, da wo auch die example liegt. Weiterhin solltest du zuerst versuchen das Paket im Browser herunterzuladen, da du so eventuelle Fehlermeldungen leichter mitbekommst.

In das Verzeichnis gepackt (example hatte ich nicht), sperrt der Server nun den Download und verlangt Name/Passwort - allerdings auch bei den Paketen, die eigentlich frei sein sollten.

Zitat von Tim

Hast du evtl den Paketserver im WCF gelöscht? Die Fehlermeldung vom WCF deutet auf irgendwie so etwas hin.

War nicht gelöscht. Aber nun bekomme ich die Aufforderung zur Authentisierung. Trotz korrekter Daten geht es dann aber nicht mehr weiter. Auch werden keine Pakete mehr gefunden, die definitiv auf dem Server liegen. Cache wurde gelöscht.

Ist die Syntax der bzw. die auth.json überhaupt korrekt?

udoz · 10. April 2014

Ach, wird überhaupt eine mit WCF identische verschlüsselung genutzt oder braucht der Server eine andere?

**Jan** · 10. April 2014

Hallo,

ich poste hier mal meine auth.json

Code

{
    "users": {
        "admin": {
            "passwd": "$2a$04$EinSaltFuerDasPassworef61b/dgzvAT4MdXS2R1ybbqbs8loVYy",
            "groups": [ "Admin" ],
            "packages": {
                "de.stricted.ldap": "$v >= 1.0.0 Beta 2 && $v < 1.0.0 RC 2"
            }
        }
    },
    "groups": {
        "Admin": {
            "*": "*"
        }
    },
    "packages": {
        "be.bastelstu.jan.wcf.apcu": "$v <= 2.0.0 pl 2",
        "be.bastelstu.jan.qWebIRC": "$v <= 1.0.0",
        "be.bastelstu.jan.wcf.githubsidebar": "$v <= 1.0.1 pl 1",
        "be.bastelstu.jan.wcf.languageswitch": "$v <= 1.0.0",
        "be.bastelstu.jan.wbb.acpstats": "$v <= 1.0.0 pl 1",
        "be.bastelstu.jan.wcf.auth.extendet": "$v <= 1.0.0 rc 1",
        "be.bastelstu.jan.wcf.wincache": "$v <= 1.0.0 pl 3",
        "be.bastelstu.jan.wcf.xcache": "$v <= 1.0.0"
    }
}

Alles anzeigen

wie du siehst habe ich beim user admin ein packet angegeben dadurch kann nur dieser benutzer es runterladen
der packet server benutzt ebenso wie das wcf bcrypt für die passwörter

**Tim** · 10. April 2014

Hallo,

erneut: Hast du mal im Browser probiert die Paketliste abzurufen? Die Startseite sollte ohne Zugangsdaten zu erreichen sein. Bei geschützten Paketen ist accessible auf false gesetzt. Ich setze die Authentifizierung hier bei meinem Paketserver selbst ein - problemlos.

udoz · 10. April 2014

Zitat von Jan

wie du siehst habe ich beim user admin ein packet angegeben dadurch kann nur dieser benutzer es runterladen

Gut, jetzt weiß ich schon mal, was oben bei Admin rein muss.
Aber die anderen Pakete müssten dann für jeden erreichbar sein. Nur werden im ACP überhaupt keine gefunden, obwohl sie definitv vorhanden sind.

Zitat von Tim

erneut: Hast du mal im Browser probiert die Paketliste abzurufen? Die Startseite sollte ohne Zugangsdaten zu erreichen sein.

Ja, ist sie. Wird im Browser server/paket eingegeben, kommt aber bei allen Paketen die Aufforderung zur Authentifizierung. Die wird aber nicht akzeptiert; auch nicht, wenn das Passwort in der auth.json leer ist.

Zitat von Tim

Ich setze die Authentifizierung hier bei meinem Paketserver selbst ein - problemlos.

Und ich weiß noch nicht einmal, wie ich die auth.json korrekt einsetze. Aber ich gehe davon aus, dass es funktionieren wird, wenn die i.O. ist

**Tim** · 10. April 2014

Hallo,

Zitat von udoz

Und ich weiß noch nicht einmal, wie ich die auth.json korrekt einsetze. Aber ich gehe davon aus, dass es funktionieren wird, wenn die i.O. ist

Die auth.json von dir sieht korrekt aus. Der Server sollte dich auf der Kommandozeile informieren, wenn diese syntaktisch fehlerhaft ist. Er verweigert dann aus Sicherheitsgründen grundsätzlich für jedes Paket den Zugriff. Wie schon gefragt: Ist accessible für Gäste jeweils korrekt gesetzt? Wenn accessible="true" ist, dann sollte das Paket ohne Zugangsdaten verfügbar sein. Fehlerhafte Zugangsdaten werfen aber weiterhin einen Fehler.

Zitat von udoz

Ja, ist sie. Wird im Browser server/paket eingegeben, kommt aber bei allen Paketen die Aufforderung zur Authentifizierung. Die wird aber nicht akzeptiert; auch nicht, wenn das Passwort in der auth.json leer ist.

Ist es möglich, dass der Browser die Zugangsdaten für die Authentifizierung zwischengespeichert hat und daher fehlerhafte Daten sendet? Übrigens: Ein leeres Kennwort wird nicht unterstützt.

udoz · 10. April 2014

Zitat von Tim

Ist accessible für Gäste jeweils korrekt gesetzt?

Sorry, aber ich habe keine Ahnung, wo das zu prüfen/setzen ist.
Ich kann nur sagen, dass vor der auth.json-Geschichte jeder ohne Einschränkung Zugriff auf den Server hatte.

**Tim** · 10. April 2014

Hallo,

anbei ein Screenshot, wovon ich rede. Das ganze ist ein Screenshot der XML meines Paketservers: https://packages.bastelstu.be/

udoz · 10. April 2014

Argh, steht bei allen Paketen auf false. Darüber hatte ich mir bislang keine Gedanken gemacht.
Stellt sich die Frage eines Ahnungslosen: wie/wo setzt man das auf true?
In Deinem Paket finde ich diese Konfigurationsmöglichkeit nicht, auch nicht in irgendeinem xsd.

**Tim** · 10. April 2014

Hallo,

der Wert wird auf Basis der Berechtigungen bestimmt. Wenn der auf überall auf false steht, dann haben nicht eingeloggte Benutzer entweder keine Rechte, oder du hast einen Syntaxfehler in der auth.json (über einen Syntaxfehler klärt dich die Ausgabe des Servers auf).

udoz · 10. April 2014

Zitat von Tim

dann haben nicht eingeloggte Benutzer entweder keine Rechte

Hier gibt es keine Benutzer, die sich einloggen könnten. Der Server läuft völlig unabhängig von einem WCF.

Zitat von Tim

oder du hast einen Syntaxfehler in der auth.json

Es gab einen.

udoz · 10. April 2014

@Tim @Jan
Danke. Läuft nun wie gewünscht.

**Tim** · 10. April 2014

Hallo,

Zitat von udoz

Hier gibt es keine Benutzer, die sich einloggen könnten. Der Server läuft völlig unabhängig von einem WCF.

Damit waren die Benutzer innerhalb des Paketservers gemeint. Aber schön, dass es sich nun lösen lies