Re: base64url format

I'm in support of such a feature, but would strongly advocate for an additional parameter to flag whether or not to include the trailing = pad. The trailing pad is optional according to RFC 4648, so I think leaving it off by default would be the ideal use case, but an optional include_padding flag or something along those lines would be helpful. On 1/9/23 10:49 AM, Sara Golemon wrote:

I've been working with JWTs lately and that means working with Base64URL format. (Ref:https://www.rfc-editor.org/rfc/rfc4648#section-5 ) This is essentially the same thing as normal Base64, but instead of '+' and '/', it uses '-' and '_', respectively. It also allows leaving off the training '=' padding characters. So far, I've just been including polyfills like this: function base64url_decode(string $str): string {

     return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -

(strlen($str) % 4)) % 4, '=')); } function base64_encode(string $str): string {

     return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');

} These work fine, but they create a LOT of string copies along the way which shouldn't be necessary. Would anyone mind if skipped RFC and just added base64url_encode() and base64url_decode() to PHP 8.3? Can hold a vote if anyone objects, but this seems fairly non-controversial. -Sara

-- Security Principles for PHP Applications <https://www.phparch.com/books/security-principles-for-php-applications/> *Eric Mann * Tekton *PGP:*0x63F15A9B715376CA <https://keybase.io/eamann> *P:*503.925.6266 *E:*eric@eamann.com eamann.com <https://eamann.com> ttmm.io <https://ttmm.io> Twitter icon <https://twitter.com/ericmann> LinkedIn icon <https://www.linkedin.com/in/ericallenmann/>