Changing language invalidates URL of existing paste in browser about privatebin HOT 5 CLOSED

I have a suggestion for the long-term solution regarding self-destroy notes.

A feature I liked about d-note, a similar project (although now unmaintained) is that when you go to the secret URL, it will ask whether you want to read the note, warning that it will destroy the note. If there was a step like this before the destruction of the note, it would allow the user a chance to change the language before pushing the button that reveals and destroys the note.

from privatebin.

Oh I can confirm there is definitively a bug in the language selector that it misses the encryption key.

However, be aware that in case you have a self-destroy paste, it still will be deleted as currently the site is reloaded when you click the language picker.

So the short-term bug should be fixable quite easily. Long-term would be a good idea to make it possible to change the language without reloading (but maybe that is also not that important).

from privatebin.

A feature I liked about d-note [...] is that when you go to the secret URL, it will ask whether you want to read the note, warning that it will destroy the note.

I dig this idea, independent of fixing the issue caused by language selection.

Trying to iterate on it: How about only applying this to self destroying notes? We could have the client display that question only if there is a parameter appended to the hash to ask for loading the paste. This would allow us to add that param to burn-after-reading notes by default, while regular notes would still get instantly displayed. And you could also manually add it to existing paste-URLs.

You could then run an instance that asks even for regular pastes/discussions, allowing you to display some TOS like "by clicking yes, read note, you agree to follow our community guidelines and understand that topics like x, y & z may get discussed" via our notice option.

from privatebin.

Yeah this has been tracked in #541 and technically kind of depends on #245 or az least that would make a good fit.

from privatebin.

Hi, not sure if this is related but I suspect it is. I have deactivated the language selection in conf.php and use English as the language, also stored in conf.php.

If a German user now opens the link with the key, it seems like (sometimes? it's not always the case not sure why) an automatic language selection is carried out, the user is led from the English to the German page and the paste can no longer be read (presumably because of the missing key in the redirect?). The error message is identical to the one in this report. I probably got around it by setting the language in conf.php to German (languageselection is still false) and thus triggering a "lang"-cookie that bypasses the behavior.

If it is to be treated as a separate bug, I would take a closer look from mid-February and create a more detailed report with reproduction steps etc. It was quite tedious to find a workaround as I have thought my installation was faulty.

Using version 1.6.0 / 1.6.2

Edit: January 20, 2024 - The issue was related to DNS. An outdated IPv6 DNS entry was occasionally causing traffic to be routed to an old PrivateBin instance, which explains the inconsistent behavior I experienced. This inconsistency was partly due to the fact that not all networks I accessed supported IPv6. Removing the outdated DNS entry resolved the issues. IPv6 was a key factor in the 'sometimes' aspect of the problem, as its support is not yet universal and made troubleshooting (mostly on IPv4 networks) a lot harder.

from privatebin.