Hallo zusammen,
ich möchte gern einen firmeninternen Podcast produzieren, der mit einem Passwort geschützt ist.
Wie kann ich das am besten anstellen, so, dass die Mitarbeiter den Podcast trotzdem mit ihren Podcatchern abonnieren können?
Habt ihr Tipps für mich?
Danke
Torsten
Was soll mit einem Passwort geschützt werden? Die Website oder auch der Feed?
Im letzteren Fall ist die Zahl von Podcast Clients, die das unterstützt, stark eingeschränkt.
Idealer Weise sollte beides geschützt sein, da man ja sonst den ungeschützten Podcast über die Website hören könnte.
Auch wenn man Benutzername & Passwort in die URL codiert? -> http://benutzer:passwort@domain.de/
Alternativ könnte man überleben, ob man eine eindeutige URL pro Mitarbeiter_in erzeugt. Verhindert zwar nicht die Verbreitung (Benutzername & Passwort de facto ja auch nicht), aber man könnte einzelne URLs einfach killen, falls sie öffentlicht werden, oder die_der Mitarbeiter_in kein Zugriff mehr haben soll.
Mir fallen da spontan mehrere Wege ein:
1.) Podcast auf Wordpress.com hosten und das ganze Blog nur für berechtigte Nutzer freischalten, den RSS-Feed intern teilen (kennt ja “draußen” niemand, security-by-obscurity). Wenn Ihr in der Firma “managed devices” habt, könnte man die Podcast-Apps sogar von einem zentralen Server aus mit dem Feed provisionieren.
2.) Interne Instanz von Wordpress nutzen
3.) iTunes scheint Passwort-geschützte Feeds zu können: https://digiredo.wordpress.com/2009/05/11/how-to-create-a-secure-podcast-channel-for-internal-podcasting/
4.) Dedizierte Corporate Multimedia-Plattform verwenden, wir haben dafür bei Kunden z.B. Vimp (https://www.vimp.com, kann auch Audio), Kaltura (http://de.corp.kaltura.com) oder Office Video (Teil von Office 365) im Einsatz
5.) Der Podcatcher Juice kann HTTPBasicAuth, gibt es aber nicht als APP
Das dumme ist, das einige Podcast-Clients diese URLs an ihre eigene Datenbank schicken, damit man dort einfach nach neuen Podcasts suchen kann. Die dumm programmierten schicken dann benutzer + passwort da rein und dann kann jeder der nach dem Namen sucht, den Podcast finden. Vorbei ist’s mit der “Security by Obscurity”. Hatte das Problem letztes Jahr schon mal 
. Wir sind zum schluss gekommen: einige Clients können HTAccess. Und dann haben wir nur diese Vorgeschrieben. Alle anderen kommen nich an die Daten. In einem Firmen-Umfeld ist das aber okaish.
Hallo zusammen,
danke für die Infos.
Wir werden jetzt das Blog mit HTTPBasicAuth schützen und den Feed irgendwie intern verteilen.
Juice werde ich mir mal anschauen.
Der Feed im Intranet (d. h. nur über VPN von außen erreichbar) klingt fast nach der besten Lösung. Selbst wenn die URL von einem Podcatcher weitergereicht wird kommt niemand ran. Und man erschlägt gleichzeitig den Zugriffsschutz sowohl auf den Feed als auch auf die Mediendateien.
Ggf so wie Google machen?:
Nein, laut @bitboxer werden die URLs von einigen Podcatchern benutzt, um ihre öffentlichen Podcast-Verzeichnisse zu füllen.
@ben.podigee wir hatten das Thema in einem anderen Thread schon und ich erinnere mich, dass ihr mit Podigee diesen Weg gehen wolltet. Seid ihr euch dieses Problems bewusst?
Nein, so weit hatte ich tatsächlich nicht gedacht. Gut das wir das noch nicht produktiv geschaltet haben… Damit fällt die Option dann wohl weg und es bleibt bestimmte Clients vorzuschreiben 
Danke auf jeden Fall an @bitboxer fürs entdecken und @ericteubert fürs Bescheid sagen.
Ich habe einmal den alten Thread ausgekramt (zwecks Verlinkung), aber ich glaube es wurde hier schon alles wichtige von damals angeschnitten:
Http-Basic Auth auf die asserts (mo3s) und „das Blog“ haben unter macOSund iOS mit erstaunlich vielen Clients sehr gut geklappt. Es gab dann ein User Name und Passwort Popup, und das von den darunter liegenden HTTP libs stammte.