adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

There is a bug in method 'upload' and 'uploadCompleted' #1551

New Issue
Open
opened 2026-10-05 00:48:06 +02:00 by adam · 0 comments
adam commented 2026-10-05 00:48:06 +02:00
Owner
Copy link
Copy source

I mentioned before on #1649 that the uploaded video is corrupted, but no answer. Unfortunately, I encountered this problem again today. Although I did not know php, I analyzed the behavior of the browser and the server. I feel that I have found the problem. The logic of the two functions 'upload' and 'uploadCompleted' has some of bug.

  1. When I upload a large file, piwigo will create a 'XXX.part' file under the 'gallery/upload/buffer' folder to store the uploaded temporary data, and the name of this 'XXX.part' seems to be a part of the file hash, so files with the same data always generate 'XXX.part' with the same name.
  2. The front-end will call 'pwg.images.upload' in turn to pass the number of pieces to the server, and the server will write the data into the 'XXX.part' file in turn
  3. The final front end calls 'pwg.images.uploadCompleted' to submit 'XXX.part' to the system

Now the problem comes if I fail to upload a file, such as the network is disconnected or the system is hibernating (using the mobile network to upload the network abnormality or the system automatically sleeps for a long time is a very common problem). After a failure I re-upload the same archive 'piwigo' tells me the upload was successful but the data stored in 'piwigo' is wrong.

For example, I transfer a file containing three chunks, chunk1 chunk2 chunk3. When uploading to chunk2 for the first time, the network is abnormal. At this time, the 'XXX.part' data stored by piwigo is chunk1+chunk2. When I found the error re-upload all went well, but 'piwigo' re-uploaded chunk1 chunk2 chunk3, so 'XXX.part' now stored chunk1+chunk2+chunk1+chunk2+chunk3 and submitted it to the system also told i succeed. When I saw the success message I thought the data was safely stored but in fact the wrong data was stored on the server which is obviously an unacceptable bug.

So when the server is processing upload, if it finds that it is chunk1, it should truncate file size to 0. But this can't solve the problem of multiple users uploading the same file at the same time, to solve this problem, you should create a different 'XXX.part' for each user.

In addition, in order to be more secure (such as preventing data from being tampered with by hackers), the 'UploadComplete' function should pass in the hash of the front-end uploaded data, and the server should verify whether the hash of the stored data is consistent.

The following is the environment when I test:

  • amd64
  • Linux Mint 20.3 Una
  • Piwigo 13.1.0
  • docker-compose 
    version: '1'
services:
  main:
    image: linuxserver/piwigo:latest
    restart: always
    ports:
      - 9000:80
    environment:
      - TZ=Asia/Shanghai
      - PUID=1000
      - PGID=1000
    volumes:
      - ./data/gallery:/gallery
  db:
    image: mariadb:10.8
    restart: always
    environment:
      - TZ=Asia/Shanghai
      - MYSQL_ROOT_PASSWORD=123
      - MYSQL_DATABASE=piwigo
      - MYSQL_USER=piwigo
      - MYSQL_PASSWORD=piwigo12345678
    volumes:
      - ./data/db:/var/lib/mysql
I mentioned before on #1649 that the uploaded video is corrupted, but no answer. Unfortunately, I encountered this problem again today. Although I did not know php, I analyzed the behavior of the browser and the server. I feel that I have found the problem. The logic of the two functions 'upload' and 'uploadCompleted' has some of bug. 1. When I upload a large file, piwigo will create a 'XXX.part' file under the 'gallery/upload/buffer' folder to store the uploaded temporary data, and the name of this 'XXX.part' seems to be a part of the file hash, so files with the same data always generate 'XXX.part' with the same name. 2. The front-end will call 'pwg.images.upload' in turn to pass the number of pieces to the server, and the server will write the data into the 'XXX.part' file in turn 3. The final front end calls 'pwg.images.uploadCompleted' to submit 'XXX.part' to the system Now the problem comes if I fail to upload a file, such as the network is disconnected or the system is hibernating (using the mobile network to upload the network abnormality or the system automatically sleeps for a long time is a very common problem). After a failure I re-upload the same archive 'piwigo' tells me the upload was successful but the data stored in 'piwigo' is wrong. For example, I transfer a file containing three chunks, chunk1 chunk2 chunk3. When uploading to chunk2 for the first time, the network is abnormal. At this time, the 'XXX.part' data stored by piwigo is chunk1+chunk2. When I found the error re-upload all went well, but 'piwigo' re-uploaded chunk1 chunk2 chunk3, so 'XXX.part' now stored chunk1+chunk2+chunk1+chunk2+chunk3 and submitted it to the system also told i succeed. When I saw the success message I thought the data was safely stored but in fact the wrong data was stored on the server which is obviously an unacceptable bug. So when the server is processing upload, if it finds that it is chunk1, it should truncate file size to 0. But this can't solve the problem of multiple users uploading the same file at the same time, to solve this problem, you should create a different 'XXX.part' for each user. In addition, in order to be more secure (such as preventing data from being tampered with by hackers), the 'UploadComplete' function should pass in the hash of the front-end uploaded data, and the server should verify whether the hash of the stored data is consistent. The following is the environment when I test: * amd64 * Linux Mint 20.3 Una * Piwigo 13.1.0 * docker-compose ``` version: '1' services: main: image: linuxserver/piwigo:latest restart: always ports: - 9000:80 environment: - TZ=Asia/Shanghai - PUID=1000 - PGID=1000 volumes: - ./data/gallery:/gallery db: image: mariadb:10.8 restart: always environment: - TZ=Asia/Shanghai - MYSQL_ROOT_PASSWORD=123 - MYSQL_DATABASE=piwigo - MYSQL_USER=piwigo - MYSQL_PASSWORD=piwigo12345678 volumes: - ./data/db:/var/lib/mysql ``` <!-- github-sync-id:1431701467 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#1551