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.
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.
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.
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.
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.