I am trying to upgrade the Lexic/JWTAuthenticationBundle from version 1.7 to 2.14. (This is in support of our upgrade of the Symfony bundle from version 3 to 4, and eventually 5).
Some of our code makes API queries with the token as a query parameter (meaning in the URL). This stopped working after we upgraded. Calls that put the token into curl request headers still work.
Here is an example of a call that works on the old setup, but not the new ($token is supplied by a previous call to our API to login):
$curl_opts = array(
\CURLOPT_URL => $our_url . "?bearer=" . $token;
\CURLOPT_SSL_VERIFYPEER => false,
\CURLOPT_SSL_VERIFYHOST => false,
\CURLOPT_RETURNTRANSFER => 1,
\CURLOPT_USERAGENT => 'cURL Request',
\CURLOPT_CONNECTTIMEOUT => 5,
\CURLOPT_TIMEOUT => 10,
\CURLOPT_HEADER => false,
\CURLOPT_CUSTOMREQUEST => GET,
\CURLOPT_POSTFIELDS => '',
\CURLOPT_HTTPHEADER => array(
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: ' . 0
),
);
$curl = curl_init();
curl_setopt_array($curl, $curl_opts);
$data = curl_exec($curl);
curl_close($curl);
This returns a 500 error, and this error message is logged:
request.CRITICAL: Uncaught PHP Exception Lexik\Bundle\JWTAuthenticationBundle\Exception\JWTDecodeFailureException: "Invalid JWT Token" at /oursymfony/vendor/lexik/jwt-authentication-bundle/Encoder/LcobucciJWTEncoder.php line 53 {"exception":"[object] (Lexik\\Bundle\\JWTAuthenticationBundle\\Exception\\JWTDecodeFailureException(code: 0): Invalid JWT Token at /oursymfony/vendor/lexik/jwt-authentication-bundle/Encoder/LcobucciJWTEncoder.php:53, Lcobucci\\JWT\\Token\\InvalidTokenStructure(code: 0): The JWT string must have two dots at /var/www/nest/core/vendor/lcobucci/jwt/src/Token/InvalidTokenStructure.php:13)"} []
If I make the same call, but add the token in the curl headers instead of the URL, the call works.
I believe we have correctly configured this to work. Here is our configuration:
lexik_jwt_authentication:
private_key_path: ""
public_key_path: ""
# ...
token_extractors:
authorization_header: # check token in Authorization Header
enabled: true
prefix: Bearer # case-sensitive...can also be an arbitrary string ('SCStoken')
cookie: # check token in a cookie
enabled: true
name: BEARER
query_parameter: # check token in query string parameter
enabled: true
name: bearer
I looked a bit at the code where the error is thrown, and noticed that on the broken call, the token is empty, but on the working call it's there.