lokale file:/// links in Chrom/e/ium (*bitte nicht hauen*)

[PHP-Neuling]

Servus liebes SelfHTML Volk :)

Ich habe ein (großes) Problem mit den gut gemeinten und sicher sehr wichtigen Sicherheitseinstellungen der Browser aus der Chromium Familie. Es geht im Detail um die Möglichkeit "lokale" Dateien über den IIS zu öffnen.

Kurz umrissen: Ich betreibe ein Intranet mit Dateisammlungen, Neuigkeiten-Sektion etc. pp. Ich administriere auch das Netzwerk im Haus (den Häusern) Ich habe keinen direkten Zugriff auf den IIS (zentral gesteuert)

Des öfteren werden über das Intranet "lokale" Dateien verlinkt. Dies hat den "charme", dass es nicht zu sinnlosen Redundanzen führt, da Menschen nun mal Menschen sind. Es wird also kein Upload auf den Server beim bereitstellen von bspw. allgemeingültigen Dokumenten durchgeführt, sondern das Dokument liegt auf einem gemeinsam geteilten Laufwerk (nennen wir es H:). Jeder user hat Zugriff auf dieses Laufwerk. Der IIS selbst nicht direkt.

Ich hufe nun das Intranet ins Jahr 2013 und baue auf PHP sowie volle Chrome-Kompatibilität um. Dabei ist mir jetzt aufgefallen, dass Chrome/Edge file:// Links blocken

Und ohne irgendwelche extensions von hacker.ru zu installieren scheint es da auch nichts zu geben was abhilft.

Dieser Zustand ist für den Betrieb eines "sauberen" Intranet's sehr schlecht. Die Kombination aus Erreichbarkeit der Daten über das Intranet, sowohl als auch über die lokalen Freigaben (H:) ist sehr günstig. Daten nicht doppelt zu haben ebenfalls.

Da ich keinen Zugriff auf den ISS habe, kann ich auch leider das entsprechende Laufwerk (H:) nicht einfach mappen.

Ich stehe etwas auf dem Schlauch :|

Habt ihr eine Idee? Vielleicht einen Workaround ?

VG und bleibt gesund

[Felix Riesterer]

Lieber PHP-Neuling,

ich lese da einige sich widersprechende Dinge.

Es wird also kein Upload auf den Server beim bereitstellen von bspw. allgemeingültigen Dokumenten durchgeführt, sondern das Dokument liegt auf einem gemeinsam geteilten Laufwerk (nennen wir es H:). Jeder user hat Zugriff auf dieses Laufwerk. Der IIS selbst nicht direkt.

Damit kann jeder User die "allgemeingültigen Dokumente" auch verändern und zurückspeichern? Soll das so sein? Warum?

Ich hufe nun das Intranet ins Jahr 2013 und baue auf PHP sowie volle Chrome-Kompatibilität um. Dabei ist mir jetzt aufgefallen, dass Chrome/Edge file:// Links blocken

Willst Du es nicht lieber ins Jahr 2021 "hufen"? Oder meintest Du hieven? Und was genau stellst Du Dir unter "Jahr 2013" genauer vor?

Die Kombination aus Erreichbarkeit der Daten über das Intranet, sowohl als auch über die lokalen Freigaben (H:) ist sehr günstig. Daten nicht doppelt zu haben ebenfalls.

Über dieses "günstig" kann man sehr geteilter Meinung sein. Für mich ist es nur dann "günstig", wenn jemand die Dokumente/Dateien lesen kann, nicht aber automatisch auch schreiben. Das sollte durch ein Berechtigungen-System geregelt werden. Und es sollte ebenso geregelt werden, wer da überhaupt an was genau dran darf.

Leider schreibst Du nicht genügend darüber, um welche Art von Daten und Dateien es sich handelt, so dass man nicht sicher beurteilen kann, wie eine sinnvollere (in Deinen Augen vielleicht nicht wirklich "bessere") Lösung aussehen könnte. Du nennst zwar "Dateisammlungen, Neuigkeiten-Sektion etc. pp.", darunter kann man sich aber je nach Fantasie die tollsten Dinge vorstellen. Eine "Neuigkeiten-Sektion" wäre für mich ein typischer Einsatzzweck für ein Blog. Wenn das über euren IIS (ISS ist etwas anderes) bereitgestellt wird, dann ist das schon die richtige Darreichungsform. Das sollte dann nicht auch noch in Dateiform (PDF? Oder etwa gar Word-Dokument?) in einem Netzlaufwerk herumgammeln.

Unter Programmierern ist inzwischen GIT als Versionierungssystem sehr verbreitet. Dort hat man die Möglichkeit auf ältere Dateiversionen zuzugreifen, wenn man das benötigt. Sollen solche Möglichkeiten auch gegeben sein?

Was ein Dokumentenmanagement-System angeht, da braucht es eine sehr genaue Bedarfsanalyse, bevor man sich auf eine konkrete technische Lösung festlegt. Immerhin ist so etwas nicht umsonst teuer.

Liebe Grüße

Felix Riesterer

[PHP-Neuling]

Hi Felix, und danke für deine Antwort, nein, der Hinweis auf 2013 war schon ernst gemeint. Topaktuell, also 2021, wären andere Vorgehensweisen modern. Aber soweit sind wir hier längst nicht. Daher meinte ich auch tatsächlich hufen, und nicht hieven. Weils für uns neu ist, aber für den Rest der Welt schon wieder 2x wiederholt.

Also summasummarum ist es so aufgebaut:

Dokumente, Vorlagen, bestimmte Ankündigung, Organigramme, etc pp. Alles Formate .pdf, .xlsx, .docx, liegen in einem geteilten Laufwerk (H:\Transfer) Hier sind sie nach sinn und Verstand sortiert. Zudem gibt es einen Unterordner "Intranet", in dem Daten weitersortiert werden, die auch für die schnelle Auffindung im Intranet vorgesehen sind. Dateien in diesem Unterordner sind schreibgeschützt (Berechtigungssystem). Nur die Administration oder QM Tante dürfen hier schreiben und schieben.

Nun teilt sich der Nutzerstamm. Einige kommen mit der lokalen Sortierung besser zurecht, und suchen sich benötigte Dokumente direkt im H:\Transfer heraus. Andere kommen mit der Navigation über das Intranet besser klar, und holen sich die Dateien (Suchfunktion, Beschreibungstexte inklusive) hier heraus.

Daher linke ich aus dem Intranet direkt ins H:, anstelle einen extra Dateiupload einzurichten. Denn dann hätte ich etliche Dateien doppelt und dreifach irgendwo liegen, mit ganz unterschiedlichen Versionsständen, da die Leute anfangen dann wild rumzukopieren.

Das war bislang auch immer cool machbar. Naja nun kommt Chrome ...

Die Neuigkeiten Sektion beinhaltet eine Art Blog. Hier wird bei Bedarf ebenfalls nochmal verlinkt. ("Die neuste Version des Organigramms finden sie <a href="">hier</a>")

Es ist also eine Datenbank vorhanden, die Dokumentennamen, deren Beschreibung sowie Bezifferung, und eben den lokalen Link bereithält (H:\Transfer\Intranet\GanzWichtigesZeug\Dokument.docx)

Eine Upload Funktion zu bauen wäre jetzt nicht das große technische Problem. Aber es wird mir langfristig viel Ärger und Arbeit machen.

Vg

[Rolf B]

Hallo PHP-Neuling,

die Security-Hürde ist da, und da hilft kein Jammern. Webseiten haben auf dem Filesystem des Computers nichts verloren. Weder direkt noch indirekt. Das ist nun mal so. Der IE hat einiges zugelassen, zum einen, weil er entstand als das Web noch jung und naiv war, und zum anderen, weil genügend Unternehmen bei Microsoft gejammert haben.

Da ich keinen Zugriff auf den ISS habe, kann ich auch leider das entsprechende Laufwerk (H:) nicht einfach mappen.

Mappen hilft Dir eh nicht so viel, für einen Dienst mappst Du nichts.

Du verwendest UNC Namen. Wenn H:\ auf das Share namens "datadump" auf dem Server "muellhalde" gemappt ist, und Du darin auf den Ordner Transfer zugreifen willst, dann lautet der UNC Name dazu: \muellhalde\datadump\Transfer

Ich habe jetzt eine Weile mit meinem lokalen IIS rumgespielt und bringe es selbst auch nicht zu Stande. Vor allem scheitere ich daran, auf meinem Heim-PC eine NTLM Authentication hinzubekommen.

Aber es sollte eigentlich möglich sein, wenn die IIS Admins Dir in deinem Web einen virtuellen Ordner /transfer anlegen und auf \muellhalde\datadump\transfer mappen. Voraussetzung, dass das funktioniert, ist natürlich eine gewisse Konstanz von Server- und Sharename.

Und dann kannst Du statt auf H:\Transfer\Tolle\Sache\news.doc auf /files/tolle/sache/news.doc verlinken, und die Datei wird vom IIS vom Share geholt und dem User zugestellt. Es ist natürlich ein Hop mehr im Datenverkehr, und der IIS wird stärker belastet.

Zugriffsrechte sollten dabei gewahrt bleiben. Der IIS weiß über ACLs (=Rechtedefinitionen) bescheid, und liefert nur aus, was erlaubt ist. Es setzt aber voraus, dass die User nicht anonym unterwegs, sondern authentisiert sind, innerbetrieblich sinnvollerweise mit NTLM oder Kerberos.

Und ja, das kannst Du nicht allein. Wer ein Web betreut, muss auch mit den Webadmins reden. Die müssen Dich im Zweifelsfall beraten können und mit Dir zusammen aushandeln, was der beste Weg ist. Wenn Du das nicht darfst, hau deinem Auftraggeber das Web um die Ohren. Wenn Du mit einer Freistil-Lösung unterwegs bist, die nicht zu deinem normalen Job gehört, und deswegen keinen Admin-Support hast (ich meine mich zu erinnern, dass das letztes Jahr mal so 'rauskam), dann mach deinen normalen Job und versuch nicht, eine relevante betriebliche Anwendung als Hobby und an den Admins vorbei zu betreiben. Das wird nichts.

Rolf

[PHP-Neuling]

Hi Rolf, und auch danke Dir für deine vielen Bemühungen

Du hattest das richtig im Kopf. Ich betreibe aber nichts "vorbei" an der zentralen IT, da dass ja leider gar nicht geht gg

Auf Nachfrage erhalte ich kein gemapptes drive. Theoretisch wäre das relativ einfach machbar gewesen. (wie du schon angemerkt hast "virtual drive" ins wwwroot gemapped)

Wenn auch Vollblutchefentwickler wie ihr mir keine saubere Lösung nennen könnt, dann geht es wohl einfach nicht.

Keine Ahnung wie ich damit jetzt weiter machen soll. Da folgen jetzt viele Gespräche mit unserer QM, wie man das nun sauber lösen kann. Hab noch keine Idee ... Im Juni kommt Chrome.

Ich danke euch für euer Ohr. So oder so war das auch sicher nicht das letzte mal, dass ich euch behellige :P

Ich fange an Freude fürs entwickeln zu empfinden :-D

Viele Grüße,

und bleibt gesund

[Rolf B]

Hallo PHP-Neuling,

Auf Nachfrage erhalte ich kein gemapptes drive.

Und damit hast Du Dich zufrieden gegeben? Sie sollen Dir eine Lösung nennen. Das ist ein Showstopper für die Chrome-Einführung.

Das Zauberwort heißt Eskalation. Damit delegiert man schwer lösbare Probleme an Leute, die schweres Geld für ihren Job bekommen. Diejenigen, die diese H:\Transfer Struktur haben wollten, müssen nun dafür kämpfen. Du als kleiner Indianer hast da wenig Chancen.

Rolf

[PHP-Neuling]

ja die Erklärung ist, dass

"wir das so sehen wie die Hersteller der Browser ... blabla"

Aufgrund der Stellung der IT im Unternehmen ist hier somit Bremse. Also Feierabend

Grüße

[Rolf B]

Hallo PHP-Neuling,

aber wenn sie es so sehen wie die Hersteller der Browser, dass ein Fileshare nicht verlinkt werden soll, dann müssen sie doch eine Alternative vorschlagen können. Ein virtuelles Verzeichnis im Web wäre eine.

Oder wollen sie, dass Du einen Sharepoint-Server für die Dokumente aufsetzt? Der liegt im Web, der übernimmt die Speicherung und enthält Ordnerstrukturen, Up- und Download, Checkin und Checkout von Dokumenten. Du kannst diverse Ablagebereiche anlegen, die von ihren Besitzern selbst administriert werden. Du kannst die Darstellung anpassen. Nicht ganz einfach zu handhaben...

Wenn das zu microsoftig ist, gibt es auch noch andere, einfachere webbasierende Dokumentablagen. Confluence, Alfresco, Samepage - google Dich schlau ;)

Denn du brauchst ja was, das von deinem Web aus verlinkbar ist. Oder streiten sie generell den Bedarf für deine Links ab?

Bei uns setzen wir in der Software-Entwicklung Azure Devops ein (ehemals Team Foundation Server). Da gibt es Buildprozesse (wofür andere makefiles einsetzen) und die erzeugen Artefakte (=erzeugte Executables, Install-Pakete, etc). Diese werden in einem Fileshare abgelegt. Microsoft hat es da so gelöst, dass sie über einen Button den Ablageordner ins Clipboard kopieren. Und den kannst Du dann im Explorer einfügen. Vielleicht reicht dir sowas ja schon als Fallback. Es sollte dann aber der UNC Name sein. Nicht H:... - denn Laufwerksmappings sind eigentlich was individuelles und du kannst nicht davon ausgehen, dass sie immer gleich sind (auch wenn ein Login-Script sie immer gleich herstellt, kann ein User das ändern).

Rolf

[PHP-Neuling]

das alberne ist ja, dass wir aktuell bzw. immer mehr sowieso voll zu Microsoft ziehen Teams, 365, etc. Da wäre ein sharepoint natürlich was lässiges. Wir haben sogar eine Firmeneigene Own/Nextcloud, die ich aber auch dafür nicht verwenden darf. Die technischen Voraussetzungen sind nicht das Problem, sondern die aufgezwungenen Hierarchien

Ist wirklich lieb von Dir, dass du Dich da jetzt immer noch so reinhängst. Ich glaube ich hatte noch kein Thema hier, indem du Dich nicht sehr aktiv und hochwertig beteiligt hast.

Vielen lieben Dank Rolf

Ich überlege die Tage mal, ob mir noch was einfällt zum Thema. Ansonsten bleibts einfach. Keine Verlinkungen mehr über's Intranet zu Dokumenten, die wir eh auch in unserer "lokalen" Ablage speichern.

Denn da hast du schon grundsätzlich recht. Das hier ist nicht meine Hauptaufgabe, sondern ich mache und pflege dies nebenbei, da ich es gerne mache. Punkt.

Vg

[Auge]

Hallo

ja die Erklärung ist, dass

"wir das so sehen wie die Hersteller der Browser ... blabla"

Das kann man so sehen, ich würde es jedenfalls tun, aber …

Aufgrund der Stellung der IT im Unternehmen ist hier somit Bremse. Also Feierabend

… dann muss von berufener Stelle auch der nun zu beschreitende Weg definiert werden. Entweder muss festgelegt werden, welcher der alten Wege (Laufwerksmapping oder Zugriff über das Intranet per Browser) bleibt und welcher entfällt oder es muss eine davon unabhängige Lösung (zum Beispiel eine selbst betriebene/gehostete Cloud (Nextcloud, Owncloud, Seafile, etc.)) bestimmt werden.

Ansonsten sitzt die EDV wie so oft zwischen Baum und Borke und bekommt von den Kollegen Feuer, weil das nicht mehr wie gewohnt funktioniert und von der Chefetage, weil es nicht beschwerdefrei läuft.

Tschö, Auge

[PHP-Neuling]

und ganz genau so ist das jetzt im Moment, und wird wohl auch so bleiben

Vg