SSL von HDD simulieren?

[Wolfgang Wolf]

Hallo,

bin hier vielleicht ein bisschen OT, weil mein Problem aber indirekt mit
JavaScript verbunden ist, finde ich hier vielleicht doch Jemanden, der
die Problematik kennt.

Ich verwende eine zxing.js um eine Webcam per HTML5 in eine Seite (im
lokalen Intranet) einzubinden. Ich lese damit einen BarCode und
verarbeite diesen in der Anwendung. Bis vor kurzem war das so, dass ich
die html-Datei neben den JavaScript-Dateien direkt auf meinem
Entwicklungsrechner auf der HDD hatte. Die html habe ich direkt per
Doppelklick öffnen können (Firefox und IE). Das geht (wahrscheinlich
nach einem Browser Update) nicht mehr.

In der Beschreibung des Herstellers steht: "getUserMedia() no longer
works on insecure origins. To use this feature, you should consider
switching your application to a secure origin, such as HTTPS."
(https://www.codepool.biz/html5-barcode-reader-javascript-webassembly.html)

Das würde die Arbeit an der Seite für mich erheblich verkomplizieren.
Gibt es einen Ausweg oder Umweg, der mir die Installation &
SSL-Konfiguration eines Servers auf meiner Entwicklungsmaschine erspart?

Auch mein Intranet (ausschließlich hausintern) braucht an dieser Stelle
auch kein SSL, da die WebApp ausschließlich lokal auf Mobil-Devices
eingesetzt wird. Die Distribution der Anwendung wir dadurch auch unnötig
verkompliziert.

Schönen Gruß
W. Wolf

[Wolfgang Wolf]

Am 13.06.2019 um 09:55 schrieb Wolfgang Wolf:

Hallo,

bin weitergekommen: Über Berechtigungen / Kamera / Einstellungen /
Kamerazugriff (Firefox) kann ich die Kamera freischalten. Muss nur noch
herausfinden, wie ich das permanent für diese eine lokale Datei oder
generell für einen bestimmten Ordner machen kann.

Also, sorry wegen der OT-Frage!

Schönen Gruß
W. Wolf

[Thomas 'PointedEars' Lahn]

Wolfgang Wolf wrote:

> bin hier vielleicht ein bisschen OT,

Nein, im Gegenteil.

> Die html habe ich direkt per Doppelklick öffnen können (Firefox und IE).
> Das geht (wahrscheinlich nach einem Browser Update) nicht mehr.

*Das* geht schon (ausser Du hast da selbst was verbastelt), nur:

> In der Beschreibung des Herstellers steht: "getUserMedia() no longer
> works on insecure origins. To use this feature, you should consider
> switching your application to a secure origin, such as HTTPS."
> (https://www.codepool.biz/html5-barcode-reader-javascript-> webassembly.html)

Die Methode wird also bei Zugriff über “file://” nicht mehr ausgeführt, weil
es sich dann um einen „unsicheren Ursprung“ handelt.

> Gibt es einen Ausweg oder Umweg, der mir die Installation &
> SSL-Konfiguration eines Servers auf meiner Entwicklungsmaschine erspart?

Nicht sinnvoll. Auch andere Features werden über “file://” bzw. “http://”
nicht oder nur eingeschränkt funktionieren, und es werden deren immer mehr.

Du solltest grundsätzlich immer auf derselben Plattform entwickeln, auf der
es später ausgeführt wird; zumindest auf einer ähnlichen. Andernfalls
riskierst Du, dass es zwar lokal funktioniert, aber später nicht.

Wobei es hier sein kann, dass es (kurzfristig) auch mit <http://localhost/>
funktioniert, Du also nicht unbedingt lokal auch SSL einrichten musst. Ich
habe das Problem nämlich mit der Geolocation API, die in Chromium mit
<http://localhost/> noch funktioniert(e); auf meiner Website, die derzeit
noch nur per <http://PointedEars.de/> erreichbar ist, aber nicht (mehr).

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[Wolfgang Wolf]

Am 13.06.2019 um 19:04 schrieb Thomas 'PointedEars' Lahn:

>
> *Das* geht schon (ausser Du hast da selbst was verbastelt):
>
Kann schon sein, früher hat's ja funktioniert. Und inzwischen tut's auch
wieder, wenn auch etwas umständlich.

>
> Die Methode wird also bei Zugriff über “file://” nicht mehr ausgeführt, weil
> es sich dann um einen „unsicheren Ursprung“ handelt.
>

Genau so ist es.

>> Gibt es einen Ausweg oder Umweg, der mir die Installation &
>> SSL-Konfiguration eines Servers auf meiner Entwicklungsmaschine erspart?
>
> Nicht sinnvoll. Auch andere Features werden über “file://” bzw. “http://”
> nicht oder nur eingeschränkt funktionieren, und es werden deren immer mehr.

Was ich schon alles unsinnvolles gemacht habe..., wie im wirklichen
Leben halt auch: Komfort geht immer vor Gewissenhaft, auch wenn's keiner
zugibt.

> Du solltest grundsätzlich immer auf derselben Plattform entwickeln, auf der
> es später ausgeführt wird; zumindest auf einer ähnlichen. Andernfalls
> riskierst Du, dass es zwar lokal funktioniert, aber später nicht.
>

Meine Plattform (bin kein WEB-Entwickler) wird mir "nur" die Daten
liefern, so wie sie auch auf meiner lokalen Platte liegen (keine
serverseitige Intelligenz, davon habe ich zu wenig Ahnung). Klar, kann
es kleine und größere Unterschiede geben, aber *no risk no fun*

> Wobei es hier sein kann, dass es (kurzfristig) auch mit <http://localhost/>
> funktioniert, Du also nicht unbedingt lokal auch SSL einrichten musst. Ich
> habe das Problem nämlich mit der Geolocation API, die in Chromium mit
> <http://localhost/> noch funktioniert(e); auf meiner Website, die derzeit
> noch nur per <http://PointedEars.de/> erreichbar ist, aber nicht (mehr).
>

Das klingt gut. Das bedeutet, ich könnte mir einen minimalistischen
"Server" suchen (???), irgendwas "portables" ohne Installation und
einfach zu konfigurieren, der auf Port 80 lauscht und dem Browser statt
“file://” das “http://” liefert. Das könnte gehen, wäre geil. Dann
könnte ich weiterhin wie bisher lokal editieren und hätte lediglich
einen anderen Browseraufruf. Mal sehen ob http://localhost ausreichend
"sicher" für meine getUserMedia() ist.

Siehst du, das meintet ich mit "Ausweg" oder "Umweg". Danke für den Tipp!

Schönen Gruß
W. Wolf

[Thomas 'PointedEars' Lahn]

Wolfgang Wolf wrote:

> Am 13.06.2019 um 19:04 schrieb Thomas 'PointedEars' Lahn:
>>> Gibt es einen Ausweg oder Umweg, der mir die Installation &
>>> SSL-Konfiguration eines Servers auf meiner Entwicklungsmaschine erspart?
>> Nicht sinnvoll. Auch andere Features werden über “file://” bzw.
>> “http://” nicht oder nur eingeschränkt funktionieren, und es werden deren
>> immer mehr.
>
> Was ich schon alles unsinnvolles gemacht habe..., wie im wirklichen
> Leben halt auch: Komfort geht immer vor Gewissenhaft, auch wenn's keiner
> zugibt.

In meinem Job als (Web-)Entwickler ist das nicht so.

> […] (bin kein WEB-Entwickler) […]

Jetzt bist Du einer. Tut mir echt leid fuer dich. [dsf 2.9]

>> Wobei es hier sein kann, dass es (kurzfristig) auch mit
>> <http://localhost/>
>> funktioniert, Du also nicht unbedingt lokal auch SSL einrichten musst.

>> […]

>
> Das klingt gut. Das bedeutet, ich könnte mir einen minimalistischen
> "Server" suchen (???), irgendwas "portables" ohne Installation und
> einfach zu konfigurieren, der auf Port 80 lauscht und dem Browser statt
> “file://” das “http://” liefert.

Du kannst zum Beispiel seit PHP 5.4 den darin eingebauten Testserver mit

php -S localhost:1337 foo.html

verwenden (Portnummer p ist beliebig 1024 ≤ p ≤ 65535). Dafür musst Du nur
PHP installieren.

<https://www.php.net/manual/en/features.commandline.webserver.php>

Am einfachsten geht das mit XAMPP, aber dann hast Du ohnehin auch den
Apache, MySQL-Server und Perl mitinstalliert.

> Das könnte gehen, wäre geil. Dann könnte ich weiterhin wie bisher lokal
> editieren und hätte lediglich einen anderen Browseraufruf.

Einen anderen _URI_, ja.

> Mal sehen ob http://localhost ausreichend "sicher" für meine
> getUserMedia() ist.

Bei mir funktioniert es *prinzipiell*:

| > navigator.getUserMedia({audio: true, video: true},
| function () { console.log('success', arguments); },
| function () { console.log('error', arguments); });
| <- undefined
|
| success
| Arguments [MediaStream, callee: ƒ, Symbol(Symbol.iterator): ƒ]
|
| > navigator.userAgent
| <- "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
| Chrome/73.0.3683.75 Safari/537.36"

> Siehst du, das meintet ich mit "Ausweg" oder "Umweg". Danke für den Tipp!

Gern.