Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


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

Re: Authorization: Bearer in "normalem" GET Request

From "Peter J. Holzer" <hjp-usenet3@hjp.at>
Newsgroups de.comp.lang.javascript
Subject Re: Authorization: Bearer in "normalem" GET Request
Date 2022-08-06 14:06 +0200
Organization LUGA
Message-ID <slrntesm9o.c54a.hjp-usenet3@trintignant.hjp.at> (permalink)
References (1 earlier) <jkv9btFrfd6U1@mid.individual.net> <slrntepjid.9hvl.hjp-usenet3@trintignant.hjp.at> <jl43ngFnghqU1@mid.individual.net> <slrnteq0ro.9slq.hjp-usenet3@trintignant.hjp.at> <jl6nf8F5papU2@mid.individual.net>

Show all headers | View raw


On 2022-08-06 08:35, Arno Welzel <usenet@arnowelzel.de> wrote:
> Peter J. Holzer, 2022-08-05 13:48:
>> On 2022-08-05 08:46, Arno Welzel <usenet@arnowelzel.de> wrote:
>>> Peter J. Holzer, 2022-08-05 10:01:
>>>> Naja, bei Basic Authentification fragt der Browser ja auch nicht
>>>> jedesmal den User, wenn er ein 401 bekommt, sondern merkt sich die
>>>> (Hostname, Realm, Username, Passwort)-Tupel. Das könnte er auch für
>>>> Bearer Authentification machen, das Problem hier ist aber, dass der
>>>> Input dafür vom Server kommt (ein Bearer-Token ist üblicherweise ein JWT
>>>> oder sonst ein signierter Blob) und nicht vom User. Man bräuchte also
>>>> die Möglichkeit, das programmatisch entweder präenptiv oder über einen
>>>> Callback zu setzen.
>>>
>>> Genau das meine ich ja - man kann den Authorization Header nicht senden,
>>> ohne ihn vorher vom Server anzufordern.
>> 
>> Äh, den Authorization Header fordert der Server an, indem er mit 401
>> antwortet. Der Browser sendet dann den Request ein zweites Mal,
>
> Dann reden wir von zwei verschiedenen Dingen. Ich dachte, es ging um das
> Token, was per API angefordert wird und *danach* als Authorization
> Header gesendet wird - also jedesmal etwas anderes.

Mit hat verwirrt, dass Du "den Authorization Header ... anfordern"
geschrieben hast. Denn den *Header* fordert der Client eben nicht an.
Und das Token hat er zu diesem Zeitpunkt längst, es geht nur darum, dem
Browser beizubringen, es auch zu verwenden.

Insgesamt war mir also ziemlich unklar, worauf Du hinauswillst.


>> bekommt ein Token. Dieses Token wird bei jedem Request in Form eines
>> Authorization Headers mitgeschickt. Das Code-Snippet hier wird
>> ausgeführt, wenn der User schon eingeloggt ist.
>
> Ja - das meinte ich. Wenn der Code ohnehin erst dann *nach* Anmeldung
> benutzt wird, dann ist es selbstverständlich kein Problem.

Wenn er vorher benutzt werden könnte, hätte sich meine Frage erübrigt,
denn dann gäbe es ja keinen Grund, sich gegenüber dem Backend zu
authentifizieren.

        hp

Back to de.comp.lang.javascript | Previous | NextPrevious 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