"Burn after reading" seems to be broken

[wuffleton]

Not sure if this is a dupe of #81, but just wanted to make sure it's on the table if it isn't.

Upon selecting the "Burn after reading" option, the paste seems to nuke itself one load too early - on the paste preview, instead of the next load after that (presumably when the recipient opens it).

For reference, I'm using the latest commit (a344dbb as of writing), and am running 0bin as a WSGI app under UWSGI+nginx if that makes any difference.

[sametmax]

The lastest commit may be broken, better use the pypi version. Is that
still not working ?

Le 04/10/2015 05:35, Null a écrit :

Not sure if this is a dupe of #81
#81, but just wanted to make
sure it's on the table if it isn't.

Upon selecting the "Burn after reading" option, the paste seems to
nuke itself one load too early - on the paste preview, instead of the
next load after that (presumably when the recipient opens it).

For reference, I'm using the latest commit (a344dbb
a344dbb
as of writing), and am running 0bin as a WSGI app under UWSGI+nginx if
that makes any difference.

—
Reply to this email directly or view it on GitHub
#90.

[wuffleton]

Version 0.5 off pypi seems to also be behaving the same way - paste autonukes itself immediately after posting.

[sametmax]

Just tested it online, I can't reproduce your bug. What's your step by
step procedure ? It is consistent in any browser ? WIthout extensions ?

Le 04/10/2015 05:35, Null a écrit :

Not sure if this is a dupe of #81
#81, but just wanted to make
sure it's on the table if it isn't.

Upon selecting the "Burn after reading" option, the paste seems to
nuke itself one load too early - on the paste preview, instead of the
next load after that (presumably when the recipient opens it).

For reference, I'm using the latest commit (a344dbb
a344dbb
as of writing), and am running 0bin as a WSGI app under UWSGI+nginx if
that makes any difference.

—
Reply to this email directly or view it on GitHub
#90.

[wuffleton]

Seems to be consistent across clean profiles on Waterfox 40.0.2 and MS Edge. Pretty much just creating a paste as normal and marking it as "burn after reading" is all I'm doing without anything fancy.

Not sure if it might be a quirk in my environment / python package versions?
I just double checked it against the builtin cherrypy server and the behavior is the same, so it doesn't seem to be nginx/uwsgi causing the issue.

If it makes any difference, I'm running it under Arch Linux, and package versions of 0bin's dependencies are as follows:
python 3.5.0-2
python-cherrypy 3.6.0-2
python-bottle 0.12.8-2
python-clize 3.0-1
python-lockfile 0.10.2-2

The only thing I can think of it being is because we recently pushed Python 3.5 to the repos, but I wouldn't think enough behavior would change that it'd cause this kind of breakage.

[sametmax]

Is the one on 0bin.net gives you the same behavior ?

Le 04/10/2015 14:42, Null a écrit :

Seems to be consistent across clean profiles on Waterfox 40.0.2 and MS
Edge. Pretty much just creating a paste as normal and marking it as
"burn after reading" is all I'm doing without anything fancy.

Not sure if it might be a quirk in my environment / python package
versions?
I just double checked it against the builtin cherrypy server and the
behavior is the same, so it doesn't seem to be nginx/uwsgi causing the
issue.

If it makes any difference, I'm running it under Arch Linux, and
package versions of 0bin's dependencies are as follows:
python 3.5.0-2
python-cherrypy 3.6.0-2
python-bottle 0.12.8-2
python-clize 3.0-1
python-lockfile 0.10.2-2

The only thing I can think of it being is because we recently pushed
Python 3.5 to the repos, but I wouldn't think enough behavior would
change that it'd cause this kind of breakage.

—
Reply to this email directly or view it on GitHub
#90 (comment).

[wuffleton]

Nope, seems to be working fine. Instead of the "paste has self destructed" message, I get the "paste will self-destruct next time it is read" message as expected.

[Shir0kamii]

I've found the culprit :

if "burn_after_reading" == self.expiration:
    expiration = self.expiration + '#%s' % datetime.now()  # TODO: use UTC dates
    expiration = self.expiration
else:
    expiration = as_unicode(self.expiration)

It seems no one has tested it since june 10th, and that 0bin.net is not up to date :p

I'll make a PR soon to fix this

[wuffleton]

I can confirm that the changes made in @Shir0kamii's pull request correct the issue on my end.

[rugk]

@wuffleton
So what about closing this issue?

[sametmax]

I'm going to revert most merge. Max is comming back this summer, and we plan to work on zerobin. We didn't take the time to check enough the PR we merged, and as a result we accepted solutions we now regret. It will take some work to undo it, then fix it, and merge it back. This comment is also answer to other requests for closing issues.

As usual, sorry for being so slow on the project. Life is passing by pretty fast this year.

[rugk]

Note that I informally consider https://privatebin.net/ to be the successor of this project, but of course I'm biased here, because I'm a co-maintainer of that project.

[ksamuel]

That's what open source is for.