Boost.Beast base64 decode
I'm decoding a Java Web Token, composed of 3 separate base64 encoded parts (header.payload.signature). Before I was using Boost.Serialization: using namespace boost::archive::iterators; using It = transform_width<binary_from_base64<std::string::const_iterator>, 8, 6>; std::string tmp(It(std::begin(base64_str)), It(std::end(base64_str))); return boost::algorithm::trim_right_copy_if(tmp, [](char c) { return c == '\0'; }); But since I'm already using Boost.Beast, I thought I'd drop the above dependency, and use this instead: using namespace boost::beast::detail; std::string decoded(base64::decoded_size(base64_str.size()), '\0'); auto rc = base64::decode(decoded.data(), base64_str.data(), base64_str.size()); decoded.resize(rc.first); But turns out some (all?) JWTs do not include the trailing equals that "proper" base64 should have. And in that case, Beast's rc.first does not include the last character, which I can still see in decoded variable prior to the .resize() in the debugger. Here's the payload part: eyJwYXNzd29yZCI6IlAiLCJ1c2VybmFtZSI6IlUifQ What it should decode to: {"password":"P","username":"U"} What Beast's decode yields: {"password":"P","username":"U" 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? JWT handling seems like a natural fit within the context of Beast, and although this is an implementation detail, it would seem logical for decode() to cope with that, no? Thanks, --DD
On Thu, 10 Dec 2020 at 17:10, Dominique Devienne via Boost-users < boost-users@lists.boost.org> wrote:
I'm decoding a Java Web Token, composed of 3 separate base64 encoded parts (header.payload.signature).
Before I was using Boost.Serialization:
using namespace boost::archive::iterators; using It = transform_width<binary_from_base64<std::string::const_iterator>, 8, 6>; std::string tmp(It(std::begin(base64_str)), It(std::end(base64_str))); return boost::algorithm::trim_right_copy_if(tmp, [](char c) { return c == '\0'; });
But since I'm already using Boost.Beast, I thought I'd drop the above dependency, and use this instead:
using namespace boost::beast::detail; std::string decoded(base64::decoded_size(base64_str.size()), '\0'); auto rc = base64::decode(decoded.data(), base64_str.data(), base64_str.size()); decoded.resize(rc.first);
But turns out some (all?) JWTs do not include the trailing equals that "proper" base64 should have. And in that case, Beast's rc.first does not include the last character, which I can still see in decoded variable prior to the .resize() in the debugger.
Here's the payload part: eyJwYXNzd29yZCI6IlAiLCJ1c2VybmFtZSI6IlUifQ What it should decode to: {"password":"P","username":"U"} What Beast's decode yields: {"password":"P","username":"U"
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?
Beast's base-64 handling has been written specifically for beast's needs so handling users' needs is not our primary concern at present. The interface you are using is in the detail:: namespace, which is by boost convention, deemed "private" to the implementation. We make no guarantees that the detail:: API will remain stable or compatible between releases or patches.
JWT handling seems like a natural fit within the context of Beast, and although this is an implementation detail, it would seem logical for decode() to cope with that, no?
From your point of view as a user, yes it would seem like a natural fit.
From our point of view as maintainers of a single-purpose library, it would not make sense to extend our public API into general-purpose base64 encoding/decoding at this time.
Happy to discuss further if you'd like. I live in the #beast channel of CppLang Slack https://cppalliance.org/slack/ R
Thanks, --DD _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
On Thu, Dec 10, 2020 at 5:29 PM Richard Hodges via Boost-users < boost-users@lists.boost.org> wrote:
JWT handling seems like a natural fit within the context of Beast, and
although this is an implementation detail, it would seem logical for decode() to cope with that, no?
From your point of view as a user, yes it would seem like a natural fit. From our point of view as maintainers of a single-purpose library, it would
not make sense to extend our public API into general-purpose base64
encoding/decoding at this time.
I'm not asking to make it public, just to tweak that implementation detail it to make it more lenient :) Happy to discuss further if you'd like.
Well, what's to discuss after the above really? I'll just use something else. Thanks for the quick reply Richard. PS: I'm a fan of Richard Hipp's (of SQLite and Fossil fame) public domain C code in general, so I'm adapting https://sqlite.org/althttpd/file?ci=tip&name=althttpd.c&ln=845-889 instead.
On Thu, Dec 10, 2020 at 8:56 AM Dominique Devienne via Boost-users <boost-users@lists.boost.org> wrote:
Well, what's to discuss after the above really? I'll just use something else.
You can copy the code into your own source file and edit to suit your needs precisely, it is very small. Thanks
On Thu, Dec 10, 2020 at 6:32 PM Vinnie Falco via Boost-users < boost-users@lists.boost.org> wrote:
You can copy the code into your own source file and edit to suit your needs
FWIW, according to https://tools.ietf.org/html/rfc7515#appendix-C, I can easily wrap Beast's encoder/decoder to yield JWT-required base64url encoding. The decoder I referenced wouldn't know about - an _ chars used in that variant anyway.
participants (3)
-
Dominique Devienne -
Richard Hodges -
Vinnie Falco