Inconsistent Image Upload Restriction Between "Attach Files" and Direct Attachment

[skyking363]

What happened?

Hi team,

I've encountered an inconsistency in how image uploads are handled when using the file attachment feature, specifically with Deepseek-R1. The behavior differs depending on how the file is attached.

Observed Behavior:

1. "Attach Files" Button (Expected Behavior):

   • When I configure fileConfig.endpoints.supportedMimeTypes to exclude image/.*, attempting to upload an image through the "Attach Files" button (highlighted in the first screenshot) is correctly blocked. I see the "Unsupported file type for endpoint" error message, as expected. This is good!

2. Direct Attachment (Paperclip Icon - Unexpected Behavior):

   • However, if I click the paperclip icon directly (highlighted in the second screenshot) without going through the "Attach Files" flow, I am able to upload images, even though image/.* is excluded in fileConfig.endpoints. This bypasses the intended restriction.

Screenshots:

Screenshot 1: "Attach Files" area and error message (Correct behavior)

Screenshot 2: Paperclip icon (Incorrect behavior)

Expected Behavior:

The image upload restriction defined in fileConfig.endpoints should apply consistently, regardless of whether the user clicks "Attach Files" or uses the direct attachment (paperclip) method. If image/.* is excluded, images should be blocked in both cases.

Request:

Could you please investigate and modify the file upload logic to ensure consistent behavior? The direct attachment method (paperclip icon) should respect the fileConfig.endpoints settings in the same way as the "Attach Files" button.

Context:

• Deepseek-R1: I'm using the Deepseek-R1 model.
• fileConfig.endpoints: My configuration intentionally excludes image MIME types (image/.*) to prevent image uploads.
• Consistency is important: Because of the security reason.

I believe this inconsistency could represent a potential security issue, as it allows users to bypass intended file type restrictions. Thank you for your time and attention to this matter!

Version Information

v0.7.7-rc1

Steps to Reproduce

Screenshots:

Screenshot 1: "Attach Files" area and error message (Correct behavior)

Screenshot 2: Paperclip icon (Incorrect behavior)

Expected Behavior:

The image upload restriction defined in fileConfig.endpoints should apply consistently, regardless of whether the user clicks "Attach Files" or uses the direct attachment (paperclip) method. If image/.* is excluded, images should be blocked in both cases.

What browsers are you seeing the problem on?

No response

Relevant log output

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

A related issue was fixed recently: #5881

Make sure to update, provide any logs and the version you are using, along with the exact librechat.yaml configuration, which was also not provided, you are using to help reproduce.

---

If using Docker, please run and provide the output of:

docker images | grep librechat

If running from source, please run and provide the output of:

git rev-parse HEAD

---

Please paste relevant logs that were created when reproducing the error.

Log locations:

• Docker: Project root directory ./logs
• npm: ./api/logs

There are two types of logs that can help diagnose the issue:

• debug logs (debug-YYYY-MM-DD.log)
• error logs (error-YYYY-MM-DD.log)

Error logs contain exact stack traces and are especially helpful, but both can provide valuable information.

Please only include the relevant portions of logs that correspond to when you reproduced the error.

Updating Instructions (docker):

# Linux command to Remove all existing images
docker images -a | grep "librechat" | awk '{print $3}' | xargs docker rmi

# Windows Powershell
docker images -a | findstr "librechat" | ForEach-Object { docker rmi $_.Split()[2] }

Then follow the directions here: https://www.librechat.ai/docs/local/docker#update-librechat

[skyking363]

@danny-avila
Below is the complete updated information. Please refer to:

---

1. Docker Images Output

ghcr.io/danny-avila/librechat-dev-api                            latest    2176088be80d   4 days ago      998MB
ghcr.io/danny-avila/librechat-rag-api-dev-lite                   latest    095db2c2ff3b   2 months ago    1.29GB

---

2. Content of the librechat.yaml Configuration File

fileConfig:
  endpoints:
    assistants:
      fileLimit: 100
      fileSizeLimit: 1024  # Maximum size for each file (MB)
      totalSizeLimit: 10240  # Maximum total size for all files in a single request (MB)
    openAI:
      disabled: true  # Disable file uploads to the OpenAI endpoint
    Deepseek:
      fileLimit: 5
      fileSizeLimit: 1024  # Maximum size for each file (MB)
      totalSizeLimit: 10240  # Maximum total size for all files in a single request (MB)
      supportedMimeTypes:
        - "text/.*"
        - "application/.*"
        - "application/x-sh"
    default:
      totalSizeLimit: 10240
      supportedMimeTypes:
        - "image/.*"
        - "text/.*"
        - "application/.*"
        - "application/x-sh"
    YourCustomEndpointName:
      fileLimit: 5
      fileSizeLimit: 1024
  serverFileSizeLimit: 102400  # Global server file size limit (MB)
  avatarSizeLimit: 2  # Maximum size for user avatar images (MB)

---

3. Correct Behavior: Blocking Video Uploads

• For correct behavior in blocking video uploads, please refer to:
  Correctly Blocking Video Uploads

---

4. Incorrect Behavior: Allowing Image Uploads

• For instances where image uploads are not being blocked, please refer to:
  Incorrectly Allowing Image Uploads

---

5. Debug Log (2025-03-01)

2025-03-01T17:57:17.030Z debug: [/files/images] Temp. image upload file deleted
2025-03-01T17:57:27.237Z debug: [AskController]
{
  text: "請描述這張圖",
  conversationId: null,
  endpoint: "Deepseek",
  endpointType: "custom",
  resendFiles: true,
  modelOptions.model: "DeepSeek-R1-Distill-Qwen-32B",
  modelsConfig: "exists",
  attachments: [object Promise]
}
2025-03-01T17:57:27.375Z debug: [BaseClient] Loading history:
{
  conversationId: "4c4dbe2a-673c-4f43-9ebc-a79f7aa305bd",
  parentMessageId: "00000000-0000-0000-0000-000000000000"
}
2025-03-01T17:57:27.468Z debug: [BaseClient] Context Count (1/2)
{
  remainingContextTokens: 2973,
  maxContextTokens: 4095
}
2025-03-01T17:57:27.469Z debug: [BaseClient] Context Count (2/2)
{
  remainingContextTokens: 2973,
  maxContextTokens: 4095
}
2025-03-01T17:57:27.469Z debug: [BaseClient] tokenCountMap:
{
  1dae01df-e027-4130-8413-adc410b5b395: 1119
}
2025-03-01T17:57:27.469Z debug: [BaseClient]
{
  promptTokens: 1122,
  remainingContextTokens: 2973,
  payloadSize: 1,
  maxContextTokens: 4095
}
2025-03-01T17:57:27.469Z debug: [BaseClient] tokenCountMap
{
  1dae01df-e027-4130-8413-adc410b5b395: 1119,
  instructions: undefined
}
2025-03-01T17:57:27.477Z debug: [BaseClient] userMessage
{
  messageId: "1dae01df-e027-4130-8413-adc410b5b395",
  parentMessageId: "00000000-0000-0000-0000-000000000000",
  conversationId: "4c4dbe2a-673c-4f43-9ebc-a79f7aa305bd",
  sender: "User",
  text: "請描述這張圖",
  isCreatedByUser: true,
  image_urls: [{"type":"image_url","image_url":{"url":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAABNMAAAMACAIAAA... [truncated] }],
  tokenCount: 1119
}

---

6. Error Log (2025-03-01)

• No error logs

---

Summary:
The system content and configuration have been updated to the latest state. The above information includes Docker images, the configuration file, links to correct and incorrect attachment behaviors, and the corresponding Debug Log. Please review this updated information and advise if further investigation is needed. Thank you!

[skyking363]

Does anyone have other ideas or solutions?

[rio100]

I believe he gave you the resolution for this already as it appears to be covered in #5880
Have you tried his update recommendations?