Privatebin: burnafterreadingselected = true doesn't work

Created on 1 Sep 2020  路  19Comments  路  Source: PrivateBin/PrivateBin

Steps to reproduce

  1. cfg/config.php change value of: burnafterreadingselected = false => true

What happens

nothing happens - preselection of the button is false (not set)

What should happen

preselection of the button is true (is set)

Additional information

pb-issue

Basic information


Server address: https://pb.pc-sam.net


Server OS: CentOS 7.8


Webserver: Apache 2.4.6


Browser: Firefox 72.2.0 ESR / Firefox 68.8.0 ESR / Chrome 84.x


PrivateBin version: 1.3.4

I can reproduce this issue on https://privatebin.net: No (eventually Yes)

UUX bug

All 19 comments

It still works on the legacy template and on the bootstrap one, the checked attribute is set, but the UI doesn't reflect this. Seems that the JS side is somehow messing this up. UI experts, please?

I get a Content Security Policy error forbidding inline script-src on your instance. I would guess it is most probably related?

I agree that it seems like a UI/UX issue on the above instance. However, I have tested with all themes on another instance and verified that this may be more than just a UI/UX issue. Even with burnafterreadingselected = true in the conf.php file, that feature does not work (i.e. the box is unchecked and proceeding will not generate a "one-time paste") on the other instance. The "Burn after reading" box must explicitly be checked before clicking Send for the feature to function there.

@Berbe The Content Security Policy error you saw could have been due to omitting the trailing slash (/) from the basepath URL in conf.php. If configured, the URL must be in format of "https://subdomain.domain.com/" with the trailing slash (/) being required there, even though the comments in conf.php do not detail that information. It looks like the above instance noted does not have that issue any longer, though.

I also have this issue, it seems to ignore the setting in conf.php - also on a subdomain

Working perfectly on my part.

@haynes11 I suppose reporting a bug by merely saing "it does not work" is never going to yield much results. Details on your setup? Anything extra that has not been mentioned already? Maybe providing a way to reproduce?

Works for me...

I think the Problem is related to the Function me.resetInput in privatbin.js. The Value for $burnAfterReading.prop('checked', false); is not changed to true, so the Button is always unchecked by loading/reloading the Page. After changing this Value to true it worked like a charm.

@LarsGlinker how does this work for you? I changed it but only get a non-functional site...
old: $burnAfterReading.prop('checked', false);
new: $burnAfterReading.prop('checked', true);
result:
image

Or what do you change exactly?

Thanks

@bikmaek If you change the JS part, you also need to re-generate the SRI hashes to make the software work. See the FAQ about this, that is also linked there: https://github.com/PrivateBin/PrivateBin/wiki/FAQ#how-to-make-privatebin-work-when-i-have-changed-some-javascript-files

@rugk thanks - this hint was good. now it's working well.

@bikmaek Also, don't change the JS files at all. Just leave everything as it is and change the config option burnafterreadingselected in the config file. That's what this issue is about.

Is it just this one setting or are other configurations not working either (changing the template would be instantly visible, for example)? If the latter, you might be affected by an issue with the caching of PHP files as described in the resolution for #746.

Hi
I'm having the same issue
Server OS: CentOS 8
Webserver: Apache 2.4.37
PHP 7.4.15
PrivateBin version: 1.3.4

I did the basic setup and everything worked
I then moved the folders outside the www & filled in the path in the index.php file
When I change f.e the default expiry date in the config file, it works (default = "1day" to default = "1week"
when I change the "burnafterreadingselected" value to true, it does't check the checkbox on load
If I however manually check the box and create a paste, it does work like it should.
It seems it is only the checkbox that isn't checked when loading the page.

kind regards

It works well for others (including myself).

Are you sure:

Could you share a link to your instance so that developers could have a look at your instance if needed?

Thanks for the reply

  • Yeah I'm im quite sure the config is beeing loaded because when I change the default expiry date, it does change it.
  • I did have a scp error:
    image

I changed the conf file to this:
cspheader = "default-src *; manifest-src 'self'; connect-src * blob:; script-src 'self' 'unsafe-eval' resource:; style-src 'self'; font-src 'self'; img-src 'self' data: blob:; media-src blob:; object-src blob:; sandbox allow-same-
origin allow-scripts allow-forms allow-popups allow-modals allow-downloads"

the scp error is now gone but the checkbox is still not working.

I'm affraid the website is not yet publicly accessible. I'll make work of this so you can have a look.

As others have already pointed out, this issue stems from the fact that the checkbox check-state is "reset" to false in me.resetInput. Simply removing the $burnAfterReading.prop('checked', false); and updating the SRI (or temporarily removing it from tpl/bootstrap.php) does the trick.

Unsure why it would work as-in for some but not others. I'm using pretty much the default settings, though with the default CSP enabled. Adding a breakpoint in Firefox shows the function gets triggered every page reload, and click of New, so yeah.

https://github.com/PrivateBin/PrivateBin/blob/5a9bcea3a919af84e275dc77c80ea270272a4663/js/privatebin.js#L4152-L4162

Oh yeah, this looks clearly like a bug. Thanks.

Though when clicking "New" it should actually be reset to the server configured default value.
As we don't have a copy of the server config on the client (another argument in favor of https://github.com/PrivateBin/PrivateBin/issues/312) that sounds like a hard thing to do.
Resetting is to an arbitrary value, i.e. the default we have set in our default config apparently, is obviously also wrong. Yeah, seems like we did never test that thing as we assumed our defaults. Sorry.

In any case, feel free to submit a PR to fix that.

Maybe one idea to fix that "reset to default server value" problem would be to include a template or other thing in the HTML that the user cannot change/click, where we can keep and safe the default value provided by the server to reset it later.
Or we just load it once at initialization from the original checkbox, which sounds like a "fun" workaround too.
This way, we could really reset it to the "correct" value.

sorry
this project has been moved a little lower on my todo list.
I'll have a look at the $burnAfterReading.prop('checked', false); trick
thank you for the comments :-)

Thank you for reporting and investigating this issue! It affected the opendiscussion setting in the same way and also ignored that they are mutually exclusive (if both are set, burnafterreading takes precedence and discussions remain disabled until the burn gets unchecked). I've added unit tests for the three cases to avoid future regressions and also added the missing handling of the expiration reset. We introduced this regression in #612 when we tried to fix resetting these options.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

EchoDev picture EchoDev  路  7Comments

elrido picture elrido  路  3Comments

aryasenna picture aryasenna  路  7Comments

HLeithner picture HLeithner  路  3Comments

elrido picture elrido  路  3Comments