Skip to content

[dotnet] [🚀 Feature]: Consider using the new Base64Url #14813

Description

@RenderMichael

Feature and motivation

With the recent release of .NET 9, the Base64Url type was released. This type fills a common need that .NET developers have, and up until recently, has been implemented, re-implemented, and polyfilled in many projects.

Selenium .NET has its own implementation: found here:
https://github.com/SeleniumHQ/selenium/blob/trunk/dotnet/src/webdriver/Internal/Base64UrlEncoder.cs

As the links in that file show, this was ripped from the Azure Active Directory implementation. They recently migrated to using the Base64Url type as well: AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#2817

Luckily for us, the .NET team released the Base64Url type as a .NET Standard 2.0 NuGet package, found here: https://www.nuget.org/packages/Base64Url

We can take this dependency unconditionally for now, and if/when we support a .NET 9+ TFM, we can conditionally remove the dependency there.

Usage example

The polyfill type Base64UrlEncoder is public (should it be internal?). Anyone currently relying on it should not be affected though.

As noted in the linked PR on Azure AD, there are minor differences in behavior between the Base64Url type and the Base64UrlEncoder type. For Azure AD, it seems like that requires them to keep the type around.

For us, we should investigate what exactly those differences are and if it would be acceptable to just use Base64Url directly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-needs-triagingA Selenium member will evaluate this soon!C-dotnet.NET BindingsI-enhancementSomething could be better

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions