Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.comp.lang.javascript Subject: Re: Authorization: Bearer in "normalem" GET Request Date: Sat, 6 Aug 2022 22:28:14 +0200 Lines: 34 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net tWPVzOK7cTQROh6CB5+KBg7CZQ7vKfa/hHMYBQMU5tf2WQ4qXQ Cancel-Lock: sha1:2f/UMS6LKYRVfP7wpRhPLlk9nx0= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.comp.lang.javascript:5320 Am 03.08.2022 um 11:56 schrieb Peter J. Holzer: > Gibt es eine Möglichkeit, den Authorization Header präemptiv zu setzen? > > Alternativen: > > 1) Ich kann im API einen nicht-authentifizierten Endpoint einrichten, > der seinerseits einen Key (als Parameter übergeben) überprüft. > 2) Ich kann den Download vom Server in JavaScript durchführen und dann > mit createObjectURL() einen blob: URL für den Inhalt generieren. > > Die 1. Lösung wird schon anderswo in der gleichen Applikation verwendet, > gefällt mir aber gar nicht. Der Key müsste ein Ablaufdatum haben, > landet, im Access-Log und möglicherweise an anderen Stellen, wo er > leaken kann ... Muss es denn ein GET sein? Das Log/Leak-Problem lässt sich auch umgehen, indem der Key als Feldwert in ein skriptgeneriertes Formular gepackt wird. Dann erscheint er in keinem der üblichen Logs und leakt nicht versehentlich. Die Sicherheit verbessert das aber nur unwesentlich. Der Mensch, der einen Link mit Auth-Parameter kopieren und archivieren kann, kann auch in den Entwickler-Tools einen Request mit Authorization-Header als curl-Kommando kopieren und archivieren. Den Auth-Parameter mit Ablaufdatum zu versehen wäre daher keine schlechte Idee. Je nachdem, was für Daten du da mit Ablaufdatum von 5 Minuten zum Download anbietest, muss der Download-Endpunkt dann nicht mal den Inhalt der ursprünglichen Authorization kennen ("wer ist der User?"), sondern nur wissen, *dass* der User korrekt autorisiert war. Wenn ich das richtig in Erinnerung habe, arbeiten CDNs von Streamingdiensten so. Stefan