<div dir="ltr">I'm decoding a Java Web Token, composed of 3 separate base64 encoded parts (header.payload.signature).<div><br></div><div>Before I was using Boost.Serialization:</div><div><br></div><div> using namespace boost::archive::iterators;<br> using It = transform_width<binary_from_base64<std::string::const_iterator>, 8, 6>;<br> std::string tmp(It(std::begin(base64_str)), It(std::end(base64_str)));<br> return boost::algorithm::trim_right_copy_if(tmp, [](char c) { return c == '\0'; });<br></div><div><br></div><div>But since I'm already using Boost.Beast, I thought I'd drop the above dependency, and use this instead:<br></div><div><div><br></div><div> using namespace boost::beast::detail;<br> std::string decoded(base64::decoded_size(base64_str.size()), '\0');<br> auto rc = base64::decode(decoded.data(), base64_str.data(), base64_str.size());<br> decoded.resize(rc.first);<br></div></div><div><br></div><div>But turns out some (all?) JWTs do not include the trailing equals that "proper" base64 should have.</div><div>And in that case, Beast's rc.first does not include the last character, which I can still see in</div><div>decoded variable prior to the .resize() in the debugger.</div><div><br></div><div>Here's the payload part: eyJwYXNzd29yZCI6IlAiLCJ1c2VybmFtZSI6IlUifQ<br></div><div>What it should decode to: {"password":"P","username":"U"}</div><div>What Beast's decode yields: {"password":"P","username":"U"</div><div><br></div><div>Is this on purpose? Could Beast's base64::decode() be changed to be more lenient about the absence of trailing equals from the base64 encoded string?</div><div><br></div><div>JWT handling seems like a natural fit within the
context of Beast, and although</div><div>this is an implementation detail, it would seem logical for decode() to cope with that, no?</div><div><br></div><div>Thanks, --DD</div></div>