Groups > de.comp.lang.javascript > #5320

Re: Authorization: Bearer in "normalem" GET Request

Path	csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From	Stefan Reuther <stefan.news@arcor.de>
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	<tcmptu.4d4.1@stefan.msgid.phost.de> (permalink)
References	<slrntekhi4.57bk.hjp-usenet3@trintignant.hjp.at>
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	<slrntekhi4.57bk.hjp-usenet3@trintignant.hjp.at>
Xref	csiph.com de.comp.lang.javascript:5320

Show key headers only | View raw

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

Back to de.comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Authorization: Bearer in "normalem" GET Request "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-08-03 11:56 +0200
  Re: Authorization: Bearer in "normalem" GET Request Arno Welzel <usenet@arnowelzel.de> - 2022-08-03 14:52 +0200
    Re: Authorization: Bearer in "normalem" GET Request "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-08-05 10:01 +0200
      Re: Authorization: Bearer in "normalem" GET Request Arno Welzel <usenet@arnowelzel.de> - 2022-08-05 10:46 +0200
        Re: Authorization: Bearer in "normalem" GET Request "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-08-05 13:48 +0200
          Re: Authorization: Bearer in "normalem" GET Request Arno Welzel <usenet@arnowelzel.de> - 2022-08-06 10:35 +0200
            Re: Authorization: Bearer in "normalem" GET Request "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-08-06 14:06 +0200
  Re: Authorization: Bearer in "normalem" GET Request Stefan Reuther <stefan.news@arcor.de> - 2022-08-06 22:28 +0200
    Re: Authorization: Bearer in "normalem" GET Request "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-08-07 09:39 +0200

csiph-web