-
Notifications
You must be signed in to change notification settings - Fork 901
Description
Did you use the FAQ section?
- Yes, I have read the FAQ and I found no solution/answer there.
When using a URL shortener hosted on an internationalized domain name (IDN), PrivateBin treats valid responses from the shortener as incorrect. As the root cause, I've located a regex in client-side JavaScript that assumes the URL is ASCII only.
https://datatracker.ietf.org/doc/html/rfc2181#page-13
https://datatracker.ietf.org/doc/html/rfc3490
Submitting this as a bug rather than a pull request because I imagine the maintainers would prefer to decide philosophically how to handle URL parsing rather than being dictated to by a stranger. :)
Steps to reproduce
- Host a URL shortener at an internationalized domain and generate an API key for PrivateBin
- Configure PrivateBin's
urlshortener
option with the API key as documented - Configure CORS to allow the shortener service
- Submit a paste in PrivateBin
- Click the "Shorten URL" button
What happens
A message appears at the top of the page saying, "Cannot parse response from URL shortener." Looking at the developer console in the browser, the AJAX request succeeded with a 200 response, and the response body contained a valid URL.
What should happen
The shortened URL in the successful response body should display. There is a regex in privatebin.js
that limits the domain portion of a URL to [-a-zA-Z0-9@:%._\+~#=]{1,256}
. If I edit this segment of the regex in the Chromium console to .{1,256}
, the shortened URL does display properly.
Incidentally, the same regex limits the TLD portion of the URL to six characters. While this isn't impacting me directly, there are many TLDs longer than six characters: https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains
One approach to a solution could be to modify the regex to include more valid domains. Another could be to require the URL shortener to represent its output in Punycode and, in JavaScript, decode the URL to its proper IDN form before displaying. Perhaps encode to Punycode, then run through a regex to validate, then decode again. Up to you how to tackle--I'm just a user. :)
Additional information
Error message:
Inline-edited regex (right) with resulting successful flow (left, domain obfuscated):
Basic information
Server OS: Alpine Linux (deployed through PrivateBin's official Helm chart, which uses the privatebin/nginx-fpm-alpine Docker image)
Webserver: nginx (deployed through PrivateBin's official Helm chart, which uses the privatebin/nginx-fpm-alpine Docker image)
Browser: Chromium 120 (also reproduced in Firefox 121)
PrivateBin version: 1.6.2
I can reproduce this issue on https://privatebin.net: No (for reasons that seem entirely logical to me :) )