Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Arno Welzel Newsgroups: de.comp.lang.javascript Subject: Re: Authorization: Bearer in "normalem" GET Request Date: Wed, 3 Aug 2022 14:52:13 +0200 Lines: 36 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net qEFAFXCduQ7XdJVSafHa7wRVnbzg3P1JswjEsLWTCx3LJNiZfA Cancel-Lock: sha1:4g/zHjWuEDZIt2RP1PDhSzwb7Ms= Content-Language: de-DE In-Reply-To: Xref: csiph.com de.comp.lang.javascript:5314 Peter J. Holzer, 2022-08-03 11:56: > Ich habe ein API, das Requests über ein Bearer Tokens authentifiziert. > Das funktioniert wunderbar, solange Requests über JavaScript (im > konkreten Fall mittels Axios) generiert und der Output wieder in > JavaScript konsumiert wird. > > Nun möchte ich aber dem User einen Download-Link anbieten. Das wäre im > einfachsten Fall einfach ein ... > oder man könnte window.location setzen. Aber der Browser weiß nichts von > dem Bearer-Token und setzt daher den Authorization Header nicht. > > Gibt es eine Möglichkeit, den Authorization Header präemptiv zu setzen? Nein. Der muss schon explizit angefordert werden. > 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 ... Sinnvoll wäre Lösung 2 nur, wenn sie Daten nutzen, die *nicht* auch vom Server vorab ohne Authentifizierung mitgeliefert werden. -- Arno Welzel https://arnowelzel.de