Meine Lesezeichen stehen in einem Lokalen HTML File, welches als Startfile im Browser (Brave / Chrome), wenn ich auf den Home Button klicke, angezeigt wird. Darin kann ich auch lokale Files referenzieren ( File://) und die werden auch im Browser angezeigt, weil es der gleiche lokale Host ist. Im Notepad ++ kann man auch urls angeben und da werden die Files nicht vom Browser sondern von der zugehörigen App angezeigt. Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit schnell eine übersichtliche Oberfläche bauen und pflegen kann. Das soll aber nur für Links die in einem Lokalen HTML File stehen funktionieren. Die Browser Erweiterungen die es gibt erlauben auch den Zugriff auf lokale Files aus dem Internet und das möchte ich nicht haben. Hat da jemand eine Idee wie man das mit HTML, JS, CSS hinbekommen könnte ?
Das geht schlicht nicht. Eventuell ging es mal im IE, aber mit heutigen Browsern geht sowas nicht mehr. Man könnte höchstens für die jeweiligen Anwendungen URI Handler registrieren, dann könnte man Dateien mit diesen Anwendungen öffnen.
Es steht dir ja frei auch einen lokalen HTTP-Server zu betreiben. Mit dem kannst du dann lokal beim Zugriff auf bestimmte URLs/MIME-Typen starten was du willst.
Daniel A. schrieb: > Das geht schlicht nicht. Ich glaube, das stimmt so nicht. Das Stichwort ist File System API. Hier mal das erste Beispiel, was ich gefunden habe: https://mburakerman.github.io/file-system-access-api-demo/ Wahrscheinlich nur mit chrome Browsern nutzbar
Du willst im Browser auf einen Link wie file:///Ordnername/datei.docx klicken und dann soll Word das direkt öffnen? Das wird kaum funktionieren. Normalerweise liegt die Datei eines Links ja auf nem Webserver. Wenn du ner App sagst "öffne mal test.com/datei.docx", dann kann die App damit meist nichts anfangen, weil die nur lokale Dateien verarbeiten kann. Da gibt es sicherlich auch Sichereheitsbedenken, die das nicht erwünschenswert machen. Was evtl. noch geht, die Datei wird "heruntergeladen" und dann direkt mit der App geöffnet. Dann wird sie aber entweder im Downloads Ordener oder in nem temporären Ordner gespeichert. Angucken geht dann, aber wenn du was änderst musst du die erst manuell wieder am richtigen Ort speichern.
Die Computer Opas sind unterwegs. Natürlich kann man Dateien mit dem Browser "öffnen". Beispiel pdf oder Office Dateien auf dem Sharepoint. Oder eine Citrix-Anwendung. Euere Grundannahme ist also falsch.
Hans-Georg L. schrieb: > Die Browser Erweiterungen die es gibt erlauben auch den Zugriff auf > lokale Files aus dem Internet Welche wären denn das? Wenn eine Browsererweiterung einen Weg durch meine Firewall bohren könnte, wäre das schon sehr bedenklich.
Hans-Georg L. schrieb: > Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit > schnell eine übersichtliche Oberfläche bauen und pflegen kann. Habe ich Dein Problem richtig verstanden: Du willst ein Fenster mit Dokumenten haben, die dann mit dem entsprechenden Programm geöffnet werden? Was stört Dich oder fehlt Dir an einem normalen Ordner-Fenster?
Walter T. schrieb: > Hans-Georg L. schrieb: >> Jetzt hätte ich gerne dieses Verhalten auch im Browser, weil man damit >> schnell eine übersichtliche Oberfläche bauen und pflegen kann. > > Habe ich Dein Problem richtig verstanden: > > Du willst ein Fenster mit Dokumenten haben, die dann mit dem > entsprechenden Programm geöffnet werden? > > Was stört Dich oder fehlt Dir an einem normalen Ordner-Fenster? Ich möchte eine lokale html Datei haben die ich frei gestalten kann, welche http-links ins Internet und File-links auf meine lokale platte enthält. Die File links sind hauptsächlich pdf, txt, bilder und code. Keine ausführbaren Dateien. File links sollen nur von lokalen html files akzeptiert werden. Beispiel für pdf files: Alle http://-links auf pdf sollen im Browser angezeigt werden und darüber auch heruntergeladen werden. Alle lokalen pdf file:// links sollen von meinem lokalen pdf reader angezeigt werden. Weil ich mit dem pdf reader in der Datei suchen und navigieren kann was im Browser nicht geht. Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ Programm werden, über json konfiguriert.
Hans-Georg L. schrieb: > Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. > Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. > Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ > Programm werden, über json konfiguriert. Gängige OSe haben dafür einen Dokumente- oder Favoriten-Ordner oder Schnellzugriffsleisten.
Max schrieb: > Du willst im Browser auf einen Link wie file:///Ordnername/datei.docx > klicken und dann soll Word das direkt öffnen? Das wird kaum > funktionieren. Klar funktioniert das. Win11 Edge macht das ohne Probleme auf.
Le X. schrieb: > Hans-Georg L. schrieb: >> Ich hoffe ich habe mich jetzt etwas verständlicher ausgedrückt. >> Mir geht es um eine Themenbezogene Darstellung, die ich anpassen kann. >> Wenn es nicht einfach und sicher mit html geht wird es halt ein c++ >> Programm werden, über json konfiguriert. > > Gängige OSe haben dafür einen Dokumente- oder Favoriten-Ordner oder > Schnellzugriffsleisten. Das ist mir zu unflexibel deshalb möchte ich was unabhängiges vom Dateisystem.
Hans-Georg L. schrieb: > Weil ich mit dem pdf reader in der Datei suchen und navigieren > kann was im Browser nicht geht. Das geht im Browser. Windows 10: Einstellungen/Apps/Apps für Websites
Rolf schrieb: > Hans-Georg L. schrieb: >> Weil ich mit dem pdf reader in der Datei suchen und navigieren >> kann was im Browser nicht geht. > > Das geht im Browser. > Windows 10: Einstellungen/Apps/Apps für Websites Und wie kann ich dann sicherstellen das das nur meine lokale html Datei darf ???? Ich will ja nicht das Sicherheitskonzept des Browsers aushebeln.
Hans-Georg L. schrieb: > Ich will ja nicht das Sicherheitskonzept des Browsers aushebeln. Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben hat.
Sherlock 🕵🏽♂️ schrieb: > Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, > öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben > hat. Er will aber nicht, dass er eine pdf oder was auch immer öffnet, die irgendwo in dem ganzboesenInternet jemand abgelegt hat. Offensichtlich ist für ihn "nicht anklicken" nicht ausreichend sicher. So zumindest habe ich ihn verstanden.
Klaus schrieb: > Er will aber nicht, dass ... Was er will würde ich lieber gerne von ihm lesen. Threads, in denen um die mutmaßlichen Ziele anderer gestritten wird, haben wir nämlich bereits reichlich.
Klaus schrieb: > Sherlock 🕵🏽♂️ schrieb: >> Welches Sicherheitskonzept? Wenn du auf eine lokale Datei klickst, >> öffnest du sie. Ist doch egal, wer den Link zur Datei aufgeschrieben >> hat. > > Er will aber nicht, dass er eine pdf oder was auch immer öffnet, die > irgendwo in dem ganzboesenInternet jemand abgelegt hat. > Offensichtlich ist für ihn "nicht anklicken" nicht ausreichend sicher. > So zumindest habe ich ihn verstanden. Der Browser kann nicht zwischen lokalen und externen pdfs unterscheiden. Aber kann (könnte) die die http:// und file://protokolle unterscheiden. a.) _href="http://www.xyz.com/demo.pdf"; b.) _href="file://D:/test/demo.pdf" Link a.) soll ganz normal behandelt werden und das pdf im Browser geöffnet werden. Link b.) soll das pdf mit meinem reader öffnen. Aber nur wenn sich dieser Link in einem (html) File lokal auf meiner platte befindet. Beides wird durch anklicken ausgelöst.
Hans-Georg L. schrieb: > Link a.) soll ganz normal behandelt werden und das pdf im Browser > geöffnet werden. Warum sollte man sowas wollen?
Hans-Georg L. schrieb: > Link b.) soll das pdf mit meinem reader öffnen. Aber nur wenn sich > dieser Link in einem (html) File lokal auf meiner platte befindet. Meinst du damit, dass "file://H:/test/demo.pdf" im Browser (nicht im PDF Reader) geöffnet werden soll, wenn H: ein Netzlaufwerk ist?
Hans-Georg L. schrieb: > Der Browser kann nicht zwischen lokalen und externen pdfs unterscheiden. Mit dem Browser würde ich das eh nicht machen. Ich habe mit AutoIT ein Miniprogramm geschrieben, mit dem die Einschränkung durchaus möglich ist. Da kann ich die Ordner/Dateien einschränken. Angezeigt werden die PDF-Dateien über das Adobe-Control. Man könnte auch das alte IE-Control nutzen, da müsste man aber an die Lesezeichen des Standardbrowsers kommen. Der IE ist zwar EOL, die IE-API ist aber auch in Windows 11 noch vorhanden und lauffähig.
Harald K. schrieb: > Hans-Georg L. schrieb: >> Link a.) soll ganz normal behandelt werden und das pdf im Browser >> geöffnet werden. > > Warum sollte man sowas wollen? Weshalb nicht? Was spricht dagegen?
Sherlock 🕵🏽♂️ schrieb: > Meinst du damit Das bezweifle ich. Es wird schon nur an file:// oder http:// liegen. Warum man davon abhängig verschiedene PDF-Renderer nutzen will, hat sich mir allerdings noch nicht eröffnet.
Harald K. schrieb: > Sherlock 🕵🏽♂️ schrieb: >> Meinst du damit > > Das bezweifle ich. Es wird schon nur an file:// oder http:// liegen. > > Warum man davon abhängig verschiedene PDF-Renderer nutzen will, hat sich > mir allerdings noch nicht eröffnet. Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser anschauen bevor ich mich entscheide es herunter zu laden. Und es geht ja nicht nur um pdfs das war ja nur ein Beispiel. Aber ich schreib mir ein kleines Programm in C++ das geht wahrscheinlich schneller als da weiter zu forschen. Wird halt dann nicht so bunt ;) Danke an alle hat sich somit erledigt.
Ich habe das gerade mal mit einem eigenen protocol handler und etwas JS ausprobiert (auf devuan linux). Der protocol handler kann beliebige shell commands ausführen. Einfach daran denken, in den Kommandos und in main.js den Namen des handlers anzupassen, ich habe `pwgen -sA 16` genommen, um mir einen Zufalls-string zu generieren. Ich missbrauche den Handler Namen als Access Token, der steht nur in der main.js, und da kommt man dank CORS nicht mit fetch usw. ran. Zum installieren:
1 | sudo cp open.desktop /usr/share/applications/ |
2 | sudo cp open.sh /usr/local/bin/ |
3 | sudo chmod +x /usr/local/bin/open.sh |
4 | xdg-mime default open.desktop x-scheme-handler/i9fw8ys62vhb831n |
Das "x-scheme-handler/i9fw8ys62vhb831n" muss auch angepasst werden, das muss gleich sein wie der Protokollname in der main.js. Danach unbedingt prüfen, ob es geklappt hat:
1 | xdg-mime query default x-scheme-handler/i9fw8ys62vhb831n |
Da muss dann "open.desktop" dabei raus kommen. Falls nicht, hat der xdg-mime aufruf nicht geklappt. Da gibt es keine Fehlermeldung, und man sucht ewig. Der Protokollname muss vollständig Kleingeschrieben sein, und es sind nicht alle Zeichen erlaubt. Und /usr/share/applications/open.desktop muss für den Benutzer lesbar sein. Das CWD wird per default im Verzeichnis mit der HTML Datei gesetzt, kann man aber anpassen. Ich habe eingebaut, dass man mit cwd="~/" das Home Verzeichnis als CWD nutzen kann. PS: In der open.sh nutze ich exo-open zum öffnen der Datei mit dem Default Programm. Wenn man das nicht installiert hat, kann man auch xdg-open nehmen. Vermutlich gibt es noch andere Programme. Edit: Zumindest in Firefox geht das. Chrome will die URL nicht öffnen, sagt "Unable to open a window with invalid URL". Keine Ahnung, was man dort noch zusätzlich einstellen müsste.
:
Bearbeitet durch User
Ok, kleine Anpassung damit es auch in Chrome geht. Chrome erlaubt URIs wie a:b:c, aber keine wie a://b/c. Merkwürdige Sache... PS: in der main.js den ":" am Ende des URI Handlers nicht vergessen!
:
Bearbeitet durch User
Re D. schrieb: > Die Computer Opas sind unterwegs. Natürlich kann man Dateien mit dem > Browser "öffnen". Beispiel pdf oder Office Dateien auf dem Sharepoint. > Oder eine Citrix-Anwendung. Euere Grundannahme ist also falsch. Nein. Es ging explizit darum, lokale Dateien zu öffnen. All der Schrott, den du anführst, zeichnet sich aber gerade dadurch aus, eben nicht lokal abgelegt zu sein. Schlimm und unsicher genug, diese Klaut-Scheiße zu verwenden. Aber immer noch ein ganzes Stück weg von dem sicherheitstechnisch ultimativen GAU, dass der Browser wirklich lokale Dateien im Kontext irgendeiner verranzten Webseite lädt. Das wäre natürlich der feuchte Traum all der verschissenen Datenkraken, aber noch sind wir nicht ganz so weit. Vorläufig jedenfalls gilt sowas noch als kritische Sicherheitslücke. Kommt aber sicher noch, dass das normal und erwünscht ist. Wenn irgendwann jungdynamische, nixwissende Typen wie du die Macht erlangen...
Hans-Georg L. schrieb: > Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser > anschauen bevor ich mich entscheide es herunter zu laden Aha. Und ... was muss der Browser machen, damit er es anzeigen kann? Er lädt es herunter. Er speichert es nur nicht dauerhaft im Dateisysstem. Toll. Dafür aber hat man den meist grottigen PDF-Renderer des Browsers (bei dem man nur hoffen kann, daß der keine interessanten Zusatzfunktionen hat), statt was anständiges.
Harald K. schrieb: > Hans-Georg L. schrieb: >> Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser >> anschauen bevor ich mich entscheide es herunter zu laden > > Aha. Und ... was muss der Browser machen, damit er es anzeigen kann? Er > lädt es herunter. > Er speichert es nur nicht dauerhaft im Dateisysstem. Toll. Dafür aber > hat man den meist grottigen PDF-Renderer des Browsers Ich weiss nicht, wie das bei Chrome ist, aber bei firefox wird soweit ich weiss intern https://mozilla.github.io/pdf.js/ genutzt. Der Reader ist also in JS geschrieben. Damit hat man auch all das übliche Sandboxing usw. was man auch bei normalen Webseiten hat. Das dürfte schon um einiges sicherer sein, als ein lokales natives PDF Reader Programm. Probleme hatte ich damit auch noch nie. Klar, Heruntergeladen wird es so oder so. Aber ich denke der Sicherheitsaspekt ist, worum es da eigentlich ging, und den hat man durchaus.
Daniel A. schrieb: > pdf.js > Probleme hatte ich damit auch noch nie. Ich hatte schon mehrfach, dass er bei Abrechnungen Teile des Textes nicht angezeigt hat. Das führte zu einem irritierten Anruf von mir bei der Sparkasse "wer zum Teufel hat die xxx Euro abgebucht?", woraus die Antwort lautete "steht doch direkt daneben!".
:
Bearbeitet durch User
Angehängte Dateien:
Für Firefox gibt es als Add-On "Local Filesystem Links". Damit kann man zumindest bei Klick auf ein lokales Verzeichnis (file://....) den Windows-Explorer öffnen. Ich benutze es, um bei einer interaktiven Suche im Browser (hier: PHP-Script) nach bestimmten Schlagworten in einer DB (hier: PostGreSQL) direkt das Verzeichnis (hier: Netzlaufwerk) öffnen zu können, zu dem es einen Treffer gibt. Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht ausprobiert. Davon steht auch nichts in der Beschreibung, siehe Screenshot.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht > ausprobiert. Wenn es so programmiert ist, wie es die (von fast niemandem jemals gelesene) Dokuentation der Windows-API vorsieht, dann entscheidet Windows anhand der Dateiextension, welches Programm zum Öffnen der Datei verwendet wird. Programme können dieses Begehr registrieren, der Explorer bietet eine UI, um diese Registrierung beeinflussen zu können (durch das "Öffnen mit"-Menü und der Checkbox "immer mit diesem Programm öffnen"). Es bestehen also gewisse Chancen, daß das einfach so funktionieren könnte, wie gedacht. Danke übrigens für den Hinweis, ich denke, daß ich damit dem einen oder anderen Kollegen helfen könnte.
Frank M. schrieb: > Für Firefox gibt es als Add-On "Local Filesystem Links". Damit kann man > zumindest bei Klick auf ein lokales Verzeichnis (file://....) den > Windows-Explorer öffnen. > > Ich benutze es, um bei einer interaktiven Suche im Browser (hier: > PHP-Script) nach bestimmten Schlagworten in einer DB (hier: PostGreSQL) > direkt das Verzeichnis (hier: Netzlaufwerk) öffnen zu können, zu dem es > einen Treffer gibt. > > Ob das auch mit Dateien wie pdf, xlsx, docx funktioniert, habe ich nicht > ausprobiert. Davon steht auch nichts in der Beschreibung, siehe > Screenshot. Das hört sich interessant an, könntest Du das bitte näher beschreiben? Danke! Nebenbei bemerkt habe ich leider die Erfahrung machen müssen, daß klassische SQL-Datenbanken zwar so etwas wie eine Volltextsuche mitliefern, aber deren Ergebnisse fand ich bisher nie sehr überzeugend. Klar, zu einem Suchstring finden sie ihre Ergebnisse, manchmal sogar mit TF-IDF, aber das war es dann leider auch schon. "Echte" Volltext-Suchmaschinen wie Apache Splunk, Elastic- und OpenSearch, oder auch Belve, errechnen für die Treffer einen Score, der die Treffer viel genauer sortieren kann als alle Nichtspezialisten, die ich kennenlernen durfte (oder mußte :-)). Die Ergebnisse werden mit diesen Scores dann in absteigender Reihen sortiert -- und bei der Berechnung dieser Scores wird berücksichtigt, wie "stark" diese Übereinstimmung ist: eindeutige Übereinstimmungen mit Worten werden höher gewertet als teilweise, und die Treffer von unscharfen (Damerau-Levenshtein) und phonetische Matches (think Double Metaphone, Soundex, Kölner Phonetik, usw.). Zudem läßt sich das sehr präzise übersteuern, wenn man muß. Ein anderer schicker Aspekt an ElasticSearch (und vermutlich auch OpenSearch, das schließlich ein Fork ist) ist es, daß mit Apache Tika "Ingest-Pipelines" erstellen lassen, die PDFs, die Inhalte von Office- und anderen Dokumenttypen direkt auslesen und indexieren können -- bei PDFs natürlich zunächst nur die mit Text-Inhalt, aber mit Tesseract gehen auch Bild-PDFs (wenngleich nicht ganz so gut wie Text-PDFs, versteht sich). Ach so, und dann sind zumindest Elastic- und OpenSearch zusätzlich zu ihren starken Fähigkeiten in der Volltextsuche auch noch sehr gut darin, Daten aus Zeitserien zu speichern, zu aggregieren und zu visualisieren. Dafür bieten sie im Falle von Elasticsearch ein Webfrontend namens Kibana und OpenSearch eines namens OpenSearch Dashboards an, mit denen man Daten durchsuchen, einsehen, aggregieren und visualisieren kann. Zuletzt bieten die Spezialisten wie Splunk, Elastic- und OpenSearch an, als geshardete und replizierte Cluster betrieben zu werden. Das ist interessant, wenn die Datenmengen so groß werden, daß sie nicht mehr (ok, zu vertretbaren Kosten) auf eine einzelne oder wenige Maschinen passen. Horizontale Skalierung (respektive Sharding) ist bei klassischen SQL-DBMS aufgrund ihrer Garantien leider immer noch problematisch (und wer Martin Kleppmanns "Designing Data-Intensive Applications" gelesen hat, weiß auch, warum), und SQL-Datenbanken wie Yugabyte (immerhin drahtkompatibel mit PostgreSQL) oder NoSQL-Datenbanken wie MongoDB scheinen viele Entwickler noch zu fürchten. Wohlgemerkt: ich möchte klassische SQL-Datenbanken und insbesondere Postgres keinesfalls schlecht reden. Aber für Anwendungsfälle wie eine Volltextsuche sind sie leider weniger gut geeignet als die Spezialisten, da beißt die Maus keinen Faden ab... Übrigens: wer Zeitseriendaten oder Logdateien hat, sollte sich vielleicht mal TimescaleDB anschauen. Das ist eine Erweiterung für PostgreSQL und ermöglicht einerseits, die bekannten SQL-Kenntnisse weiter zu nutzen, aber andererseits sind entsprechend konfigurierte Tabellen für viele Anwendungsfälle deutlich performanter als Plain PostgreSQL. Naja, zurück zum Thema: ich würde mich sehr freuen, wenn Du vielleicht ein paar Worte über Deinen speziellen Anwendungsfall äußern könntest. Danke! :-)
Hans-Georg L. schrieb: > Wenn ich im Internet ein pdf anklicke möchte ich es erstmal im browser > anschauen bevor ich mich entscheide es herunter zu laden. Und es geht ja > nicht nur um pdfs das war ja nur ein Beispiel. Aber ich schreib mir ein > kleines Programm in C++ das geht wahrscheinlich schneller als da weiter > zu forschen. Wird halt dann nicht so bunt ;) Danke an alle hat sich > somit erledigt. Weil mich die Fragestellung interessiert, habe ich jetzt mal ein bisschen mit Golang herumgespielt. Wie sich in der "main.go" in den Kommentaren zeigt, hab ich dort einige Möglichkeiten ausprobiert und noch keine befriedigende Lösung gefunden, wobei: ich hab's bisher auch nur mit dem Feuerfuchs versucht. Leider habe ich bisher keine wirklich sinnvolle Lösung gefunden, vielleicht könnte Daniels Lösung mit einem eigenen Protocol Handler oder etwas mit dem Content-Type MIME-Multipart funktionieren. Wer mag, ist natürlich jederzeit herzlich zum Mithacken eingeladen. Ach so: in dem Ziparchiv befinden sich je ein ausführbares Executable für Linux und Windows auf AND64-Architektur, die aus Platzgründen beide mit UPX komprimiert sind. Die kann natürlich löschen und das Zeugs mit make(1) selbst neu übersetzen, wer eine Golang-Toolchain oder -Container hat. Viel Spaß! :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.