nothing happens - preselection of the button is false (not set)
preselection of the button is true (is set)
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)
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:

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

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.
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.