Boost.Beast base64 decode

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Boost.Beast base64 decode

Boost - Users mailing list
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

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Beast base64 decode

Boost - Users mailing list


On Thu, 10 Dec 2020 at 17:10, Dominique Devienne via Boost-users <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
Richard Hodges
office: +442032898513
home: +376841522
mobile: +376380212


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Beast base64 decode

Boost - Users mailing list
On Thu, Dec 10, 2020 at 5:29 PM Richard Hodges via Boost-users <[hidden email]> 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,

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Beast base64 decode

Boost - Users mailing list
On Thu, Dec 10, 2020 at 8:56 AM Dominique Devienne via Boost-users
<[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: Boost.Beast base64 decode

Boost - Users mailing list
On Thu, Dec 10, 2020 at 6:32 PM Vinnie Falco via Boost-users <[hidden email]> wrote:
You can copy the code into your own source file and edit to suit your needs

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.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users