bartek commented on code in PR #1712:
URL: https://github.com/apache/tika/pull/1712#discussion_r1555919713
##########
tika-pipes/tika-fetchers/tika-fetcher-http/src/main/java/org/apache/tika/pipes/fetcher/http/jwt/JwtGenerator.java:
##########
@@ -0,0 +1,64 @@
+package org.apache.tika.pipes.fetcher.http.jwt;
+
+import java.time.Instant;
+import java.time.temporal.ChronoUnit;
+import java.util.Date;
+
+import com.nimbusds.jose.JOSEException;
+import com.nimbusds.jose.JWSAlgorithm;
+import com.nimbusds.jose.JWSHeader;
+import com.nimbusds.jose.JWSSigner;
+import com.nimbusds.jose.crypto.MACSigner;
+import com.nimbusds.jose.crypto.RSASSASigner;
+import com.nimbusds.jwt.JWTClaimsSet;
+import com.nimbusds.jwt.SignedJWT;
+
+public class JwtGenerator {
Review Comment:
One thing we need to support is the `qsh` claim addition for Atlassian JWTs,
see:
https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/
This `qsh` claim takes the incoming request URL (ie download URL) and
computes a hash from it. My thinking is we could send the calculated value of
the `qsh` claim as part of FetchAndParse, and it would be amended to the claims
during token generation. Every request would of course create a new JWT as this
`qsh` claim value would be different.
Is that possible in this workflow?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
