[Bug]: File uploads fine, it's GET that is the problem

[marcthenarc]

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]

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 the server/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]

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]

:D I just thought that might be the case since I've never tried using a host without a top-level domain (except for localhost in development).

[marcthenarc]

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]

Are you sure it isn't like 54 instead? 64 is beyond the current line count in this file.

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_URL environment variable as BASE_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]

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]

So is that a configuration thing or a genuine bug?

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