PrivateBin
-
Describe the problem/questionI'm self-hosting PrivateBin on Linux/Apache, using the filesystem to store pastes. When I create and then view a burn-on-reading paste, I can see that the corresponding file gets created and then deleted. But if I reload the page in my browser (currently using Chrome), or visit the URL in another browser tab, then I can pull up the same paste again. If I visit the URL in another browser or an incognito window, then the paste is not available, as expected. It seems like there's some caching going on, probably at the browser level. Is this a bug, or is there some config option I missed? Did you use the FAQ section?
What you did?
What happensWhenever I reload the tab or visit the URL in a new tab, I am able to see the paste, even though I can see on the server that the paste file is gone. What should happenThe paste should not display. Additional informationOn privatebin.net, although I get the popup indicating that burn-on-read pastes can only be read once, the actual paste does not display on subsequent loads. ("Could not get paste data: Paste does not exist, has expired or has been deleted.") Is privatebin.net also using the filesystem? Server addressNo response Server OSUbuntu WebserverApache PrivateBin versionv1.7.1 Browser and versionChrome and Edge latest Local operating system and versionWindows 11 Issue reproducibilityNo, I cannot reproduce it on https://privatebin.net. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
|
I cannot reproduce this on either Chromium or Firefox either, sorry. If I understand correctly, you only get this on your own instance, not on the privatebin.net demo instance? If yes, that would rule out your browser, it would either be a difference in headers sent to the browser, that makes it cache the API response, or the webserver caching it? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, that looks right. When I visit the URL of a burn-on-read paste, the initial call to But on my site, the subsequent ajax call to Shouldn't the
|
Beta Was this translation helpful? Give feedback.
-
|
I'm happy to submit a PR if this seems like an appropriate change. |
Beta Was this translation helpful? Give feedback.
-
|
That does sound like a good idea. Yes, the JSON responses should not ever get cached. A PR would be greatly appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
I'm on my way out of town for a few days, will be happy to take care of this when I return. |
Beta Was this translation helpful? Give feedback.
-
|
Ref (as PRs do not seem to be linked in discussions), fixed in #1263 |
Beta Was this translation helpful? Give feedback.
Yes, that looks right. When I visit the URL of a burn-on-read paste, the initial call to
?<id>returns with cache controlno-store, no-cache, no-transform, must-revalidate. It looks like this is set inController.php, in the_viewmethod.But on my site, the subsequent ajax call to
?pasteid=<id>returns withmax-age=172800and I suppose the browser is caching that. (On privatebin.net, the ajax call returns with nocache-controlheader.)Shouldn't the
__constructmethod set the same cache control headers as_view, so that JSON responses don't get cached? I just added it there in my copy, and now burn-on-read pastes behave as expected.