WebDAV – Basic oder ein Bearer-Token
tls {
cert_file = "/etc/fileshare/tls/fullchain.pem"
key_file = "/etc/fileshare/tls/key.pem"
}
serve "webdav" {
addr = "0.0.0.0:443"
tls = true
}HTTP Basic oder ein Bearer-Token – über TLS, aus Dateien oder über ACME.
Nicht unverschlüsselt, seit v0.9.0
HTTP Basic ist das Passwort bei jeder Anfrage, und ein Bearer-Token ist so gut
wie eines. WebDAV ohne TLS, auf einer Adresse, die andere Maschinen erreichen können,
während sich irgendjemand authentifiziert, wird beim Start abgelehnt –
serve "webdav" { addr = "0.0.0.0:8080" }, das Beispiel, das diese Seite früher
zeigte, startet nicht mehr. Wenn ein Proxy davor TLS terminiert, geben Sie das an:
serve "webdav" {
addr = "10.0.0.5:8080"
plaintext = true
}Loopback und ein Server, bei dem sich niemand authentifiziert, sind nicht betroffen. Siehe TLS.
404, nicht 403
Eine Freigabe, die eine Person nicht nutzen darf, antwortet mit 404. Ihre Existenz wird nicht bestätigt.
Ein Token, über das eine Protokoll, das eines tragen kann
oidc {
issuer = "https://login.example.org"
audience = "fileshare"
}Ein Browser hat ein Token und kein Passwort. Daher akzeptiert WebDAV Authorization: Bearer, und wo es auch lokale Personen gibt, bietet die gesendete Challenge
beides an – ein Client wählt das, worauf er antworten kann. Das Token wird von
go-authn/oidc geprüft: Signatur, Aussteller, Zielgruppe,
Ablauf.
Ein Bearer-Token: nur WebDAV
SMB authentifiziert mit NTLMv2, SFTP mit einem Schlüssel oder einem Zertifikat, NFS mit
gar nichts und S3 mit einer SigV4-Signatur: Keines davon hat einen Platz für
einen Authorization-Header. Das ist eine Tatsache der Protokolle, keine
Grenze dieses Programms.
Das Wort des Anbieters erreicht SFTP stattdessen in einem Zertifikat – siehe SFTP. Eine Konfiguration, die einen Anbieter nennt und weder WebDAV noch ein solches SFTP bereitstellt, wird abgelehnt statt gestartet.
Ein Token sagt, für wen der Anbieter jemanden hält. Es sagt nicht, dass dieser Server eine Freigabe für ihn hat.
Ein gültiges Token für einen Namen, den keine Quelle hier kennt, wird abgelehnt – die sichere Lesart
von Ich kenne Sie nicht ist nicht Sie dürfen. Ebenso wenig erhält ein Name, den auch ein lokales
Konto trägt, dieses Konto, sofern nicht local_names = true angibt, dass die
Namen des Anbieters die dieses Servers sind (standardmäßig aus, seit v0.20.0); ohne
diese Einstellung wird ein solches Token ebenfalls abgelehnt, es sei denn, eine oidc:-Regel benennt die Person.
Eine Site, bei der der Anbieter das Verzeichnis ist, gibt das an:
oidc {
issuer = "https://login.example.org"
audience = "fileshare"
trust_all = true # everybody that provider vouches for, not just these people
}Hier gibt es keinen Anmeldeablauf: keine Weiterleitung, kein Client-Secret, keine Cookies. Dies ist der Ressourcenserver.
Der Name, den ein Token liefert, ist preferred_username oder der Claim, den
username_claim nennt. Ohne preferred_username ist es die E-Mail-Adresse nur, wenn
der Anbieter email_verified: true angibt, und andernfalls sub. Mit
username_claim = "email" wird ein Token, dessen E-Mail-Adresse nicht verifiziert ist, abgelehnt –
über WebDAV ebenso wie für eine opkssh-Anmeldung über SFTP. Bis sie verifiziert ist,
ist die E-Mail-Adresse nur das, was die Person eingetippt hat, und ein signiertes Token, das sie trüge,
würde an eine Adresse binden, die niemand geprüft hat (OpenID Connect Core 5.1;
go-authn/oidc v0.2.0, fileshare v0.16.3).
Welche Personen des Anbieters eine Freigabe erhalten – Gruppen, benannte Personen, ganze
Einrichtungen –, wird mit oidc:-Regeln und domains festgelegt; siehe
Personen, die der Identitätsanbieter benennt.
Ein Token überdauert die Person, sofern nichts anderes es sagt
Ein Token wird hier für sich allein geprüft und ist gültig, bis es abläuft – was auch immer
der Person seitdem widerfahren ist. Keine Sperrliste kann es benennen. Ein
ssf-Block sorgt dafür, dass ein CAEP-session-revoked
vom Anbieter jedes zuvor (iat) ausgestellte Token ungültig macht.
Die Wurzel, und Uploads in Stücken
Die Wurzel listet die Freigaben (seit v0.29.0). Ein Browser auf / bekommt
eine Seite mit den Freigaben, die er öffnen darf; ein PROPFIND auf / bekommt
sie als Collections (207), sodass ein Dateimanager den ganzen Server statt
einer Freigabe einbinden kann. Tiefe infinity wird abgelehnt (403,
propfind-finite-depth, wie RFC 4918 es erlaubt), ebenso alles, was an der
Wurzel schreiben würde (405). Bis v0.28 bekam jede Methode auf / die Seite.
Ein großer Upload kann in Stücken erfolgen (seit v0.29.0). Ein PUT wird
vollständig im Speicher gehalten, bis 1 GiB; ein Client, der nicht streamen
kann — ein Browser, der Datei-Explorer —
sendet daher ein leeres PUT, dann jedes Stück mit einem Content-Range, das
genau dort beginnt, wo das vorige endete, dann ein MOVE auf den richtigen
Namen. Ein Bereich, der hinter dem Ende beginnt, bleibt 416: Er hinterließe
Bytes, die niemand gesendet hat.
Erstellt am von tannevaled
Geändert am von tannevaled