[SOLVED] Squidex cloud: Images uploaded via API are not being recognized as images

I have…

  • [ ] Checked the logs and have provided the logs if I found something suspicious there

I’m submitting a…

  • [x] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

Uploading of assets (images) via API are being converted to just blobs instead of images. The response model for the API infact returns isImage: false. This was working 10 days ago where the same client code was upload the assets.

If I download the blob manually from the assets and rename it to .jpg, it render the image usable on the local machine.

API Response for POST /api/apps/ivagaming/assets

  "id": "cbf40f21-f9d3-4e7d-959a-275af18b077b",
  "parentId": "00000000-0000-0000-0000-000000000000",
  "fileName": "HACKSAW_GAMING_KoiCash_screenshot",
  "fileHash": "Rgdp2mJ770gvFLV7A0aRqKl5JXT/lWzXr4l2c0+ocIg=",
  "isProtected": false,
  "slug": "hacksaw-gaming-koicash-screenshot",
  "mimeType": "image/jpeg",
  "fileType": "blob",
  "metadataText": "28.9 kB",
  "metadata": {},
  "tags": [
  "fileSize": 29581,
  "fileVersion": 0,
  "type": "Unknown",
  "createdBy": "client:ivagaming:contentapi",
  "lastModifiedBy": "client:ivagaming:contentapi",
  "created": "2020-01-24T11:33:11Z",
  "lastModified": "2020-01-24T11:33:11Z",
  "version": 0,
  "isImage": false,
  "_links": {...}

Expected behavior

Expected behaviour is for Squidex to recognize and mark the asset as an image as it used to do before; where isImage was being correctly set to true

API Response for POST /api/apps/ivagaming/assets from 10 days ago:

  "id": "97ea848e-743f-433c-b462-55cd566e0b41",
  "parentId": "00000000-0000-0000-0000-000000000000",
  "fileName": "PRAGMATIC_PLAY_NATIVE_WildGladiators_screenshot",
  "fileHash": "r+fKgyAPomZwFUI0IgSYtSbiNrB0Yx9a5dmYaII+97U=",
  "slug": "pragmatic-play-native-wildgladiators-screenshot",
  "mimeType": "image/jpeg",
  "fileType": "blob",
  "tags": [
  "fileSize": 86331,
  "fileVersion": 0,
  "isImage": true,
  "pixelWidth": 600,
  "pixelHeight": 413,
  "createdBy": "client:ivagaming:contentapi",
  "lastModifiedBy": "client:ivagaming:contentapi",
  "created": "2020-01-14T09:43:07Z",
  "lastModified": "2020-01-14T09:43:07Z",
  "version": 0,
  "_links": {...}

Minimal reproduction of the problem


  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Version: Current cloud version of Cloud Squidex (can’t find where the version is)


  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

The uploading of the asset through the browser works fine. It’s only when uploading through the API that the assets are not being converted and tagged properly.

Do you think you can provide me a small sample to reproduce it?

Sample of code or images?

Both would be perfect.

So the images zip file can be downloaded from this link: https://ioo.ovh/JdMRU

Unfortunately the code is proprietary and I cannot send the inner workings of it; however we’re using RestSharp 106.6.2 and this method does the preparation of the RestRequest which is sent to Squidex:

public async Task<AppAsset> UploadAsset(byte[] assetDataBytes, string assetFileName, AssetTypes assetType)
    string mimeType;
    switch (assetType)
        case AssetTypes.JPG: mimeType = System.Net.Mime.MediaTypeNames.Image.Jpeg; break;
        case AssetTypes.PNG: mimeType = "image/png"; break;
        case AssetTypes.GIF: mimeType = System.Net.Mime.MediaTypeNames.Image.Gif; break;
        default: mimeType = System.Net.Mime.MediaTypeNames.Image.Jpeg; break;

    // This works with RestSharp 106.6.2 through the framework's way of handling multi-part form data
    var uploadAssetRestRequest = new RestRequest($"/api/apps/ivagaming/assets", Method.POST, DataFormat.Json);
    uploadAssetRestRequest.AddFile("file", assetDataBytes, assetFileName, mimeType);
    uploadAssetRestRequest.AddParameter("filename", assetFileName, ParameterType.GetOrPost);
    uploadAssetRestRequest.AddParameter("filetype", mimeType, ParameterType.GetOrPost);

    return await ExecutePost<AppAsset>(uploadAssetRestRequest);

The ExecutePost add the bearer token header. The initialization of the RestClient is using the default constructor

var restClient = new RestClient("https://cloud.squidex.io");

In the mean time I’ll start working on a summary .NET Core app to reproduce the issue, although we haven’t done any updates these past 2 weeks so I’m fairly certain that the client code should still be working as it was 10 days ago.

I have replaced the image detection with a library that also detects other formats such as videos and audios and can extract a wide range of metadata. Probably there is a but there.

Currently I am also work on a API test suite, so I will add it to there as a test.

See: https://github.com/Squidex/squidex/pull/475/files

If this change went live within the past 10 days, then that is probably what’s causing this change in behaviour. Let me know if I can provide you with more information.

I found it. The reason is that the new tagging library uses the file extension as well. For me it works when I upload the name with a file extension

e.g. https://github.com/Squidex/squidex/pull/475/files#diff-3725f81460f301ed77b38b4e1bafbef0R44

I see. I was under the impression that the mimeType would be used for detecting what kind of image it is. So final question: is using the filename extension how it’s going to be from now on, or are you going to re-introduce image type detection based on mimeType?

My question revolves around whether I need to assign resources to make changes to adhere to this new behaviour.

The mime type was never used. The old solution has tried to open the image. I will get this back as an fallback.

Ah! Understood. Alrite then it seems that the ‘proper’ way is to add the extension to the filename, since the old solution should only be used as a fallback.

Alrite, I’ll get on it since we need to upload these assets asap.

Confirmed. Adding the jpg extension fixed the issue of images not being recognised.

1 Like