JavaScript QR Code - Unterscheiden zwischen "gescannten" Aufruf oder Direktaufruf einer Url

[BugTomcio]

Hallo Zusammen,

ich möchte gerne wissen ob es einen einfachen Weg gibt zu unterscheiden, ob der Nutzer einen QR-Code (Link) gescannt oder den Link direkt im Browser aufgerufen hat? Es soll keine zusätzliche App dafür verwendet werden, lediglich eine einfache Barcode-Scanner-App in verbindung mit einem Link-QR-Code, der rest sollte dann direkt auf der Zielseite ablaufen.

mir fallen spontan nur die "unschönen" und ziemlich ungenauen Lösungen ein:
- Prüfen ob sich der Nutzer in der Nähe des QR-Codes befindet (html/geolocation)
- Prüfen ob ein bestimmtes WLAN-Netzwerk erreichbar ist

Habt ihr eine andere Idee?

 

[MD5003]

QR code auf eine eindeutige Seite verlinken.
Z.B. subdomain, oder eine bestimmte Datei.
Anders kaum sinnvoll lösbar.

 

[BugTomcio]

Das löst nicht mein Problem. Gibt es eine Möglichkeit dafür zu sorgen, dass der Nutzer einen Link NUR über den QR-Code und NICHT direkt über Url-Eingabe im Browser azfrufen kann?

 

[Lawnmower]

Wenn er die URL kennt kann er sie ja jederzeit wieder aufrufen - reicht ja z.B. schon wenn das Browser Tab offen bleibt und das bei einem Browser Neustart neugeladen wird.

Würde allenfalls gehen wenn der QR Code an einem Bildschirm abfotografiert werden müsste und jedesmal mit einer eindeutigen ID neu generiert wird (z.B. aufgrund eines vorhergehenden Workflows) - aber selbst dann kann man nicht verhindern dass ggf mehrere Personen gleichzeitig den Code fotografieren.

Über Geo wäre eine Idee - aber das muss man als Client ja nicht zwingend freigegeben haben - ausserdem wäre das kein Garant dass da immer was sinnvolles kommt - im dümmsten Fall verärgert man die User.
Das mit der WLAN Sichtbarkeit würde m.W.n. nur mit einer nativen App (oder einer der Native Scripts Derivate) gehen - die müsste der User aber sicher vorher installieren - da hat man eine vollständige Web URL schnell abgetippt.

 

[Jesterfox]

Mach den Link für den QR-Code so kompliziert das man sich grundsätzlich immer vertippt ;-)

Nein, eine andere Lösung gibt es nicht. Dein Webserver bekommt vom Browser nur mit welche URL er haben möchte, aber nicht woher er diese hat.


Einziger Ausweg wäre wenn es um spezielle Geräte geht bei denen du Zugriff auf die genutzte Software hast.

 

[max_1234]

Als Entwickler solltest du wissen dass deine Frage Quatsch ist, da QR-Code Apps nichts anders machen, als das was du versuchst zu erkennen - eine bestimmte Seite direkt aufrufen.

mfg,
Max

 

[fRaNkLiN]

Billiglösung: Basic-Auth-URL bauen, sowas wie http://user:supersecurepassword@example.com, und diese als QR-Code hernehmen. Dann wäre der direkte Seitenaufruf wegen der Basic Auth nicht möglich. Negativpunkt: sobald jemand den QR-Code gescannt hat, kennt er Username und Passwort im Klartext und kann die Seite ab da auch jederzeit manuell besuchen.

Zweite Billiglösung: An die URL einen Authentifizierungsparameter anhängen, der nach dem Aufruf der Seite durch einen Redirect gelöscht wird. So könnten direkte Aufrufe ohne Token geblockt werden. Auch hier wäre allerdings der Nachteil, dass der User bei bekanntem Token (den er nach dem Scannen des Codes sehen kann) die Seite danach direkt aufrufen kann.

Ansonsten ist es ohne weitere Schutzmechanismen - Geofencing hast du bereits angesprochen - unmöglich, einen direkten Aufruf von einem Aufruf durch eine Scanner-App zu unterscheiden.

 

[BugTomcio]

Danke für die zahlreichen Reaktionen.

 

[crvn075]

Billiglösung: Basic-Auth-URL bauen, sowas wie http://user:supersecurepassword@example.com, und diese als QR-Code hernehmen. Dann wäre der direkte Seitenaufruf wegen der Basic Auth nicht möglich. Negativpunkt: sobald jemand den QR-Code gescannt hat, kennt er Username und Passwort im Klartext und kann die Seite ab da auch jederzeit manuell besuchen.

Zweite Billiglösung: An die URL einen Authentifizierungsparameter anhängen, der nach dem Aufruf der Seite durch einen Redirect gelöscht wird. So könnten direkte Aufrufe ohne Token geblockt werden. Auch hier wäre allerdings der Nachteil, dass der User bei bekanntem Token (den er nach dem Scannen des Codes sehen kann) die Seite danach direkt aufrufen kann.

Ansonsten ist es ohne weitere Schutzmechanismen - Geofencing hast du bereits angesprochen - unmöglich, einen direkten Aufruf von einem Aufruf durch eine Scanner-App zu unterscheiden.

Das ändert doch rein gar nichts. Der Link bleibt ein Link, ob da jetzt Authentifizierungsdaten eingebaut sind oder nicht.

Wenn das nur statistischen Zwecken dienen soll, dann wäre ein zusätzlicher Parameter schon diskutabel, also sowas wie www.homepage.de?origin=QR_7834759875. Wenn dieser Link ausschließlich im QR-Code benutzt wird, dann wäre das schon relativ zuverlässig, denn keiner wird das zufällig im Browser eingeben. Aber wer Lust hat, kann den Link trotzdem aus dem Bild herausholen und damit machen, was er möchte.

 

[fRaNkLiN]

Das ändert doch rein gar nichts. Der Link bleibt ein Link, ob da jetzt Authentifizierungsdaten eingebaut sind oder nicht.

Wenn das nur statistischen Zwecken dienen soll, dann wäre ein zusätzlicher Parameter schon diskutabel, also sowas wie www.homepage.de?origin=QR_7834759875. Wenn dieser Link ausschließlich im QR-Code benutzt wird, dann wäre das schon relativ zuverlässig, denn keiner wird das zufällig im Browser eingeben. Aber wer Lust hat, kann den Link trotzdem aus dem Bild herausholen und damit machen, was er möchte.

Du schlägst das Gleiche vor wie ich.

Die Basic Auth hat den selben Effekt wie dein zusätzlicher GET-Parameter, nur dass die Zugangsdaten nicht mehr überprüft werden müssen, denn wenn sie fehlen, wird der Webserver den Besucher selbsttätig abweisen.

 

[Jesterfox]

Wenns nur um eine halbwegs zuverlässige Statistik geht wer über direktes Scann des QR Codes kommt würd ich das auch über einen kryptischen Parameter machen und den als aller erstes per Redirekt entfernen. Keiner wird den Code so abtippen und wer im Browser ein Bookmark setzt oder den Link rauskopiert erwischt durch den Redirect die Version ohne dem Parameter. Wobei ich den Aufruf ohne dem Parameter nicht abweisen sondern nur anders in der Statistik erfassen würde.

 

[crvn075]

@fRaNkLiN

Ich weiß, ich sagte doch, ein zusätzlicher Parameter (der rein zur Erkennung der Herkunft dient) wäre diskutabel, wenn man keine exakte Genauigkeit braucht. Und wie der Parameter jetzt aussieht ist egal. Was hier aber Authentifizierung und "Zugangsdaten" bringen sollen, ist mir jedoch schleierhaft.

 

[BugTomcio]

Wir kommen der Sache näher. Ich kann einen kryptischen parameter mit übergeben und den anschließend aus der url via Script unmerkbar verändern (Zeichen mitten drin). Ein Bookmark verweist dann auf die Seite mit dem veränderten parameter.

 

[crvn075]

Genau, so kannst du das machen wenn das für deine Zwecke ausreicht.
Du solltest dir nur bewusst sein, dass du trotzdem nicht mit Sicherheit sagen kannst, wie der Link geöffnet wurde. Bei dem Parameter handelt es sich nur um einen Indikator.

Die meisten QR-Reader für's Handy zeigen ja den Link an, bevor man auf die Seite umgeleitet wird und das wäre dann eben der "präparierte" Link. Wenn sich der Nutzer dann entscheidet, diesen zu Kopieren und in Whatsapp zu verteilen, dann ist das so.