Christian Seiler: Authentifizierung gegen ein über HTTP erreichbares SVN-Repos

Beitrag lesen

Hallo Christoph,

Der IMHO wichtigste Unterschied: Tomcat hat mich in den Wahnsinn getrieben, Resin nicht. ;-)

Oha. Ist zwar glaubhaft, aber keine solide technische Beschreibung der Unterschiede *g*

:-)

(Zugang ohne HTTP Auth für Teile des Repositories hat technisch zu derartigen Problemen geführt, dass wir's bleiben gelassen haben.)

Da würden mich Details interessieren,

Problem ist folgendes: Wir verwenden das mod_authz_svn-Modul, um die Berechtigungen im SVN zu definieren. Wir haben nun Teile des Repositories, die öffentlich zugänglich sind und Teile, die es nicht sind (auf gibt's auch keine Leserechte). Wenn wir HTTP-Auth-losen Zugang zum Repository zulassen, dann funktioniert ein »svn co http://gesamtes/repository« nicht mehr, weil dann nur der öffentliche Teil des Repositories ausgecheckt wird, selbst wenn man als User die Berechtigung hätte, alles (oder zumindest mehr) zu sehen. Warum? Weil svn wie jeder andere HTTP-Client auch grundsätzlich immer erst einmal den Request ohne Zugangsdaten stellt und erst wenn nach diesen gefragt wird, diese mitschickt (was auch in Ordnung ist). Der Reqest, den Inhalt des Hauptverzeichnisses des Repositories zu lesen, führt aber nicht dazu, dass der Webserver nach den Zugangsdaten fragt, weil Auth-loser zugang ja möglich sein soll. Also bekommt derjenige, der das gesamte Repository auschecken will, nur den öffentlich zugänglichen Teil vorgesetzt. Passiert aber nicht nur im Hauptverzeichnis, sondern in jedem Verzeichnis, das Unterverzeichnisse enthält, von denen Teile Auth-los zugänglich sind und Teile nicht. Gut, gesamtes Repository auschecken ist vielleicht nicht etwas, was jeder machen will, aber so Dinge wie der Repository Browser von TortoiseSVN zeigen, außer man gibt den Unterpfad explizit an, auch immer nur den öffentlichen Teil an, wenn man es so macht.

Was wir eine Zeit lang gemacht haben, war, unter /repos/ grundsätzlich Zugangsdaten zu verlangen und unter /anon-repos/ ein Alias auf das Repository zu haben, was ohne Zugangsdaten lesbar ist. Hat im Prinzip auch funktioniert. Ist allerdings genau dann auf die Schnauze geflogen, als wir svn:externals-Referenzen eingebaut haben: Wenn Du z.B. wie Du vmtl. auch gemacht hast den Pfad https://vms.selfhtml.org/repos/projekte/sdml-servlet/ auscheckst, dann ist dort ja SELFHTML selbst nicht enthalten, sondern wirklich nur die Servlet-Daten. Der Rest wird nachgeladen (siehe den Abschnitt "Property svn:externals set to"). Wir wollen SELFHTML ja nicht an 3 Stellen auf einmal im Repository haben. Wenn es aber 2 Repository-Pfade gibt (/repos/ und /anon-repos/), dann ist die Frage, was man nun in die svn:externals-Referenz schreibt: Schreibt man einen Pfad mit /repos/ rein, stoßen die Leute, die sich das über /anon-repos/ auschecken wollen, auf Probleme, weil sie kein Passwort haben, um auf /repos/ zuzugreifen. Schreibt man /anon-repos/ rein, kann sich das zwar jeder auschecken, aber wenn jemand, der daran arbeitet und Schreibrechte hat, darin etwas comitten will, wird er scheitern, weil /anon-repos/ keinerlei Schreibzugriffe überhaupt zuließ.

Und bevor wir das ganze Zeug dann noch ewig weiter verkompliziert hätten, haben wir uns einfach gesagt: /anon-repos/ wird gestrichen, neuer Username 'anonymous' mit gleichem Passwort für den anonymen Zugang, /repos/ grundsätzlich nur mit User, das ist die einfachste Lösung, die am wenigsten Kopfzerbrechen bereitet.

Das ganze ist also ziemlich SVN-spezifisch und hat nichts mit dem HTTP-Auth zu tun, was man in 99,999% aller anderen Fälle einrichtet.

Da gibts auch nochwas: du hast ein paarmal irgendwelche "Servertipps" hier im Forum verlinkt.

Guck mal in meine Signatur. ;-)

Viele Grüße,
Christian