The library currently supports loopback redirect URIs with the http scheme for the addresses 127.0.0.1 and ::1 without specifying a port, aligning with the best practices for OAuth2 applications on native devices as per RFC8252. However, the hostname localhost, which is commonly used and interchangeable with 127.0.0.1 in most development environments, is not explicitly supported. This can lead to slight confusion as developers are required to use IP addresses directly, which may not always be ideal, particularly in environments where localhost is prevalently used.
Proposed Change
I propose that we extend the validation logic to include localhost as a recognized hostname for loopback addresses. This change would allow developers to use localhost in redirect URIs without having to resort to numeric IP addresses, thus enhancing usability and consistency across different development setups.
Current Validation Line
Change to:
and parsed_allowed_uri.hostname in ["127.0.0.1", "::1", "localhost"]
Rationale
Including localhost in the list of valid loopback addresses would enhance the developer experience and align the library with common development practices where localhost is preferred over direct IP addresses. It's a minor change that could make the library more intuitive and user-friendly without compromising security or functionality, as localhost is effectively synonymous with 127.0.0.1 and ::1 within the context of loopback addresses.
Impact
This change would be backward-compatible, broadening the validation scope to include an additional, commonly used hostname. It will benefit developers by allowing more flexibility in redirect URI configurations without negatively impacting existing implementations.
Problem Description
The library currently supports loopback redirect URIs with the
http
scheme for the addresses127.0.0.1
and::1
without specifying a port, aligning with the best practices for OAuth2 applications on native devices as per RFC8252. However, the hostnamelocalhost
, which is commonly used and interchangeable with127.0.0.1
in most development environments, is not explicitly supported. This can lead to slight confusion as developers are required to use IP addresses directly, which may not always be ideal, particularly in environments wherelocalhost
is prevalently used.Proposed Change
I propose that we extend the validation logic to include
localhost
as a recognized hostname for loopback addresses. This change would allow developers to uselocalhost
in redirect URIs without having to resort to numeric IP addresses, thus enhancing usability and consistency across different development setups. Current Validation LineChange to:
Rationale
Including
localhost
in the list of valid loopback addresses would enhance the developer experience and align the library with common development practices wherelocalhost
is preferred over direct IP addresses. It's a minor change that could make the library more intuitive and user-friendly without compromising security or functionality, aslocalhost
is effectively synonymous with127.0.0.1
and::1
within the context of loopback addresses.Impact
This change would be backward-compatible, broadening the validation scope to include an additional, commonly used hostname. It will benefit developers by allowing more flexibility in redirect URI configurations without negatively impacting existing implementations.