mirror of
https://github.com/plankanban/planka.git
synced 2026-02-05 00:39:58 +03:00
[Bug]: File uploads fine, it's GET that is the problem #644
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marcthenarc on GitHub (Feb 4, 2025).
Where is the problem occurring?
I encountered the problem while interacting with the server (Backend)
What browsers are you seeing the problem on?
Firefox, Microsoft Edge
Current behaviour
Currently, upload works fine. A newly upload is located in /private and matches the directory association in the attachment table in Postgres. However, it's the reading back that is faulty.
The request:
http://raspberrypi/attachments/1438212723203638303/download/thumbnails/cover-256.png.Obviously, there is no actual path that resembles this request as attachments are located in the top private/ directory. I suspect that the server uses some for of mod_rewrite to extract the path as parameters, fetch the database for the real path, then push it back to the browser.
The rewrite seems to fail and takes the path literally.
Desired behaviour
Would like to see the actual attachment I sent.
Steps to reproduce
I'm using the attachment button on the card and upload a file from my disk. Then nothing is seen on the card. Running the same step with the inspector show this error.
This is to prove that uploading images is possible, here are two successful attempts at uploading.
Their location in the database:
Other information
No response
@meltyshev commented on GitHub (Feb 4, 2025):
Hi! I just re-checked this using the exact same domain, and wasn’t able to get the 404 error. The issue might be due to a lack of read permissions, but that’s just a guess. You can try logging the error itself by adding
sails.log.warn(error);on line 64 to theserver/api/controllers/attachments/download-thumbnail.js.Btw, it looks like we should add more error logging in cases like this. This would make it much easier to identify issues.
@marcthenarc commented on GitHub (Feb 4, 2025):
Hi, and thanks. I wasn't expecting people to try the link, that's why I added markup quotations to show it as a command and to demonstrate the steps I went through: it's on my home network (and I thought raspberrypi without a top-level like .com, .org would be a dead giveaway :-) )
I'll try this later this evening. Just posting this so that people don't bang their heads on 404s again.
@meltyshev commented on GitHub (Feb 4, 2025):
:D I just thought that might be the case since I've never tried using a host without a top-level domain (except for
localhostin development).@marcthenarc commented on GitHub (Feb 5, 2025):
Those Pis are great. I have at least 4 running for various services around home.
Are you sure it isn't like 54 instead? 64 is beyond the current line count in this file.
In all cases, if I put it in 54, I didn't see any more error reporting, local logging, etc. I'm a C++ developer. I don't know how you guys get away without a decent debugger :-)
I thought I'd post the debug output from my Firefox:
Don't mind the first io error. The server behaves wildly when a change in file occurs (such as adding your warning).
I'm more interested in the NS_BINDING_ABORTED or the OpaqueResponseBlocking.
If it's a reading permission, in what would be it different then a successful write in terms of configuration? When a write is successful, it's rare that a read isn't.
FWI: The server on the Pi is the default Apache2 Debian server. Debian is the distro the raspberry pi OS is forked from.
@meltyshev commented on GitHub (Feb 5, 2025):
Oops, you're right, it should be line 54.
Based on the logs from your console, you're using port 1337. This means it should also be included in the
BASE_URLenvironment variable asBASE_URL=http://raspberrypi:1337. This is most likely the issue - without specifying the port, the attachment link is built without it, so requests don't reach Planka at all, which is why there are no error logs.@marcthenarc commented on GitHub (Feb 5, 2025):
Yup, called the image directly with :1337 and it worked.
So is that a configuration thing or a genuine bug?
I didn't choose 1337. It was part of the install process (looking under stacks of papers) somewhere ...
@meltyshev commented on GitHub (Feb 5, 2025):
It's just a configuration, not a bug. You can either add a proxy server to forward requests to port 1337 or run Planka on port 80 by
node app.js --prod --port=80. In both cases, you can omit the port number in theBASE_URL.