From aa470d297ed4286807178ae1fbf6290340bdbd5e Mon Sep 17 00:00:00 2001 From: Chris Bobbe Date: Wed, 22 Dec 2021 12:58:08 -0800 Subject: [PATCH] api: Properly encode non-ASCII emails for HTTP auth headers The base64.encode function requires all the code points in its input to be in the range U+0000..U+00FF. Effectively it requires that it can type-pun the string as a string of bytes, because the Base64 encoding itself is defined on sequences of bytes. But email addresses aren't restricted to that range, and haven't been for a long time. RFC 6532, "Internationalized Email Headers", dates to 2012. So some users have email addresses containing code points outside that range, and we should handle them so that those users are able to use the app. Here in the HTTP basic-auth header, one is generally supposed to do so (though the spec stops short of quite mandating this) by encoding the user-id and password -- which for Zulip means the user's email and API key -- in UTF-8, and then Base64-encoding those bytes. And indeed that's what the Zulip server expects. See discussion: https://chat.zulip.org/#narrow/stream/378-api-design/topic/Non-ASCII.20email.2Fapi_key.3F/near/1300660 So do that here. [greg: wrote new commit message] --- src/api/transport.js | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/src/api/transport.js b/src/api/transport.js index 8759576c616..186eefe3e52 100644 --- a/src/api/transport.js +++ b/src/api/transport.js @@ -1,11 +1,10 @@ /* @flow strict-local */ -import base64 from 'base-64'; - import type { Auth } from './transportTypes'; +import { base64Utf8Encode } from '../utils/encoding'; export const getAuthHeaders = (auth: Auth): {| Authorization?: string |} => // The `Object.freeze`` in the `:` case avoids a Flow issue: // https://github.com/facebook/flow/issues/2386#issuecomment-695064325 auth.apiKey - ? { Authorization: `Basic ${base64.encode(`${auth.email}:${auth.apiKey}`)}` } + ? { Authorization: `Basic ${base64Utf8Encode(`${auth.email}:${auth.apiKey}`)}` } : Object.freeze({});