Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119252
MIME-Version: 1.0
References: <CAESVnVo3NyM_RGybyLQSko0F=fBSnSWG3gkVZtU-DS8W=79fdA@mail.gmail.com>
 <A93F2A9D-BA70-4C0D-8496-581B0DA0C829@derickrethans.nl> <CA+p1FaacnhCr9715ar8FQc-Tv2a8mUe6hZCoMw17kKBQzzhDcQ@mail.gmail.com>
In-Reply-To: <CA+p1FaacnhCr9715ar8FQc-Tv2a8mUe6hZCoMw17kKBQzzhDcQ@mail.gmail.com>
Date: Tue, 10 Jan 2023 13:01:40 +0100
Message-ID: <CAJmy8YFgagmgw4ET5Hy=P2XmkUOptbiWGjrPES2bqq5goLDvNQ@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: Derick Rethans <derick@derickrethans.nl>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] base64url format
From: divinity76@gmail.com (Hans Henrik Bergan)

how about base64_encode(string $string, int $flags = 0): string
with $flags accepting BASE64_RFC4648 and BASE64_NO_PADDING
or something to that effect?

On Mon, 9 Jan 2023 at 22:56, David Gebler <davidgebler@gmail.com> wrote:
>
> On Mon, Jan 9, 2023 at 9:42 PM Derick Rethans <derick@derickrethans.nl>
> wrote:
>
> > On 9 January 2023 18:49:28 GMT, Sara Golemon <pollita@php.net> 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?
> >
> > Should these be new functions, or options to base64_encode instead? I'd
> > guess base64_decode could just accept both?
>
>
> I think from a UX/DX perspective, separate functions would be my
> preference, base64_url_encode and base64_url_decode (extra underscore which
> I feel is more consistent with PHP stock library). One consideration though
> is that base64_urlencode or base64_url_encode are function names which are
> likely already defined by a number of userland projects or libraries, since
> it's a very common thing to do with the prevalence of JWTs, so if the RFC
> process is being bypassed in this case, a new optional parameter to
> base64_encode might be better. But I think it would be weird to have
> base64_encode(bool $urlEncode = false) or something, which is presumably
> what it would look like.
>
> Dare I float the suggestion of a Base64 class, making base64_encode and
> base64_decode functions aliases for Base64::encode() and Base64::decode()
> respectively, then new Base64::urlEncode() and urlDecode() methods?