આવતી bearer વિનંતી રિસોર્સ સર્વર સુધી પહોંચી શકે છે જ્યારે JWT ચકાસણી બહાર જતા JWK ડાઉનલોડ પર નિષ્ફળ જાય છે. તે ડિકોડર વાપરતા HTTP ક્લાયન્ટને ગોઠવો:

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));

એપ્લિકેશનના વાસ્તવિક jwkSetUri અને issuer વાપરો અને આ ડિકોડરને વાસ્તવિક રિસોર્સ-સર્વર કન્ફિગરેશનમાં સ્થાપિત કરો. ઉદાહરણ servlet-શૈલીના Nimbus ડિકોડર સાથે પ્રમાણીકરણ વગરનું HTTP પ્રોક્સી વાપરે છે. મંજૂર જાહેર-પ્રોક્સી માર્ગ પરના જાહેર JWK URL માટે HTTP પ્રોક્સી સૂચિ સંભવિત host અને port મૂલ્યો પૂરા પાડે છે.

ઉદાહરણનું issuer વેલિડેટર જરૂરી audience કે એપ્લિકેશનની અન્ય ચકાસણીઓનો વિકલ્પ નથી. આપોઆપ ગોઠવાયેલ ડિકોડર બદલતી વખતે તેમને જાળવી રાખો; કી-ડાઉનલોડ માર્ગ બદલવાથી એ નિર્ધારિત થતું નથી કે એપ્લિકેશન કયા ટોકન સ્વીકારવા જોઈએ.

રિએક્ટિવ ડિકોડર બીજું ઇન્ટરફેસ વાપરે છે. અન્ય issuer-શોધ કે ટોકન-મેળવણી ક્લાયન્ટ પણ પોતાનું પરિવહન કન્ફિગરેશન જાળવે છે.

કેશ કરેલી કી નવા ડાઉનલોડ વિના ચકાસણી સફળ કરી શકે છે. માર્ગનું મૂલ્યાંકન કરતી વખતે નિષ્ફળ કી URL અને રિફ્રેશ કે ઇનિશિયલાઇઝેશન તબક્કો જાળવી રાખો.

સંબંધિત લેખો