Envenanta bearer-peto povas atingi la resursservilon dum JWT-kontrolo malsukcesas ĉe elira JWK-elŝuto. Agordu la HTTP-klienton uzatan de tiu malkodilo:

var factory = new org.springframework.http.client.SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
var rest = new org.springframework.web.client.RestTemplate(factory);

var decoder = org.springframework.security.oauth2.jwt.NimbusJwtDecoder
    .withJwkSetUri(jwkSetUri)
    .restOperations(rest)
    .build();
decoder.setJwtValidator(
    org.springframework.security.oauth2.jwt.JwtValidators
        .createDefaultWithIssuer(issuer));

Uzu la realajn jwkSetUri kaj issuer de la aplikaĵo kaj instalu ĉi tiun malkodilon en la fakta agordo de la resursservilo. La ekzemplo uzas neaŭtentikigitan HTTP-prokurilon kun la servlet-stila Nimbus-malkodilo. Por publika JWK-URL sur permesita publika prokur-vojo, la listo de HTTP-prokuriloj provizas kandidatajn gastiganto- kaj pord-valorojn.

La issuer-validigilo en la ekzemplo ne anstataŭas postulatajn audience-kontrolojn aŭ aliajn aplikaĵkontrolojn. Konservu ilin kiam vi anstataŭigas aŭtomate agorditan malkodilon; ŝanĝi la ŝlosil-elŝutan vojon ne difinas, kiujn tokenojn la aplikaĵo devas akcepti.

Reaktiva malkodilo uzas alian interfacon. Aliaj klientoj por issuer-malkovro aŭ token-akiro ankaŭ konservas sian propran transportan agordon.

Kaŝmemorigitaj ŝlosiloj povas igi la kontrolon sukcesa sen nova elŝuto. Konservu la URL-on de la malsukcesa ŝlosilo kaj la ĝisdatigan aŭ inicialigan stadion kiam vi taksas la vojon.

Rilataj artikoloj