Forum Discussion
Decode base64 underscore not accepted
Hi ,
Im trying to decode based64 (JWT) using irule , on regular basis this works great .. but right now i found when there is an underscore "_" in payload the request breaks with the following error : "conversion error (line 1) invoked from within....."
I used "cache" in irule to eliminate the error and the service not effected, but there is no data from decoding when found underscore .
(After double checked when eliminating the false character and decoding works perfect)
I used the following (small part of the irule) but this is were i stuck ..
Is there any way to solve it ?
Regards ,
if { [HTTP::header exists Authorization] && [HTTP::header value "Authorization"] contains "Bearer" } {
catch {
set finds [string range [HTTP::header Authorization] [expr {[string first "Bearer " [HTTP::header Authorization]] + 7}] end]
#log local0. "Find String :$finds"
set header [getfield $finds "." 1]
set payload [getfield $finds "." 2]
log local0. "header : $header"
log local0. "payload : $payload"
set HBearer [b64decode $header]
set PBearer [b64decode $payload]
log local0. "Decode Header : $HBearer"
log local0. "Decode Payload : $PBearer"
}
}
- Stanislas_Piro2
Cumulonimbus
"-" and "_" characters are not valid base64 characters... In JWT format, this is not base64 but base64url
according to https://tools.ietf.org/html/rfc4648
Base 64 Encoding with URL and Filename Safe Alphabet
The Base 64 encoding with an URL and filename safe alphabet has been
used in [12].
An alternative alphabet has been suggested that would use "~" as the
63rd character. Since the "~" character has special meaning in some
file system environments, the encoding described in this section is
recommended instead. The remaining unreserved URI character is ".",
but some file system environments do not permit multiple "." in a
filename, thus making the "." character unattractive as well.
The pad character "=" is typically percent-encoded when used in an
URI [9], but if the data length is known implicitly, this can be
avoided by skipping the padding; see section 3.2.
This encoding may be referred to as "base64url". This encoding
should not be regarded as the same as the "base64" encoding and
should not be referred to as only "base64". Unless clarified
otherwise, "base64" refers to the base 64 in the previous section.
This encoding is technically identical to the previous one, except
for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
Table 2: The "URL and Filename safe" Base 64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 - (minus)
12 M 29 d 46 u 63 _
13 N 30 e 47 v (underline)
14 O 31 f 48 w
15 P 32 g 49 x
16 Q 33 h 50 y (pad) =
So to decode each value, you must first replace - with + and _ with /
set HBearer [b64decode [string map {- + _ /} $header]] set PBearer [b64decode [string map {- + _ /} $payload]]
- Rotem
Nimbostratus
Hi Stanislas Piron ,
Thank you for the great information , I just finish trying the string map and got the same error
"conversion error (line 1) invoked from within "b64decode [string map {- + _ /} $payload]"
Seems like string cannot apply because the decode function dont work when "_" is found .
What im doing wrong ?
- Stanislas_Piro2
Cumulonimbus
can you try this and check logs...
the string map may replace - with + and _ with /
set header [string map {- + _ /} [getfield $finds "." 1]] set payload[string map {- + _ /} [getfield $finds "." 2]] log local0. "header : $header" log local0. "payload : $payload" set HBearer [b64decode $header] set PBearer [b64decode $payload]
- Rotem
Nimbostratus
hi ,
thanks again , but same issue when tested "conversion error (line 1) invoked from within "b64decode $payload""
- Rotem
Nimbostratus
Hi,
After testing all again I found the issue is not what I thought. . "_" do not cause my decoding failure at all.
I assume this is caused by jwt token, maybe it encoding with diffrent encryption or what ever.
When I used online decoding and re-encoding with exact parameters the f5 can decode without any problem.
I will try read more about it probebly im missing something. ..
*in the past I used netscaler and it worked, so ill focus on the way netscaler do it .
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com