Resized Image REST API Broken in 10.3.2.7882?

Community Version: 10.3.2.7882

For any request using the /resized-image rest api endpoint, the application is throwing a 403 forbidden response at me. The IIS App Pool identity has access to the requested folder in the filestorage.  This is only happening for images using /resized-image.  Is this a known bug?

Example:

community/resized-image/__size/512x256x1/__key/communityserver-blogs-components-weblogfiles/00-00-00-00-06/7651.fake.image.jpg

Response: You do not have permission to view this directory or page.

Status Code: 403

Parents Reply
  • I also just found that the /resized-image controller will return 403 only if the image is located in certain numbered folders. For example, this returns a 403 for me:

    /resized-image/__size/512x256/__key/communityserver-blogs-components-weblogfiles/00-00-00-00-41/1.png

    But if I copy that same exact image into the "45" folder, it returns a proper image:

    /resized-image/__size/512x256/__key/communityserver-blogs-components-weblogfiles/00-00-00-00-45/1.png

    Permissions on this file and on the entire structure are set the same - all inherited from the filestorage root.

Children
  • Jeff,

    I sent you an update on your open case. Based on the behavior above it sounds like the issue isn't because of the permissions on the fileStorage but the permissions tied to the accessing user's roles/permissions within the platform.

    Let me know when you're open to dig a bit deeper here.

  • Michael, I appreciate the help as always.  We were able to determine the cause of these problems and steps for resolution.

    For blog posts that were created and then moved to another blog application, the physical image file and PostImageUrl does not get moved/updated to reference the new blog id in the file path.  If you then delete the original blog application (which I did), even though the folder still exists in the filestorage, the application no longer sees that blog id in the database and does not allow access to the files which throws the 403.

    To resolve the issue, I will need to determine which blog posts have images located in folders other than their own blogid folder, physically copy those images to the appropriate folder, and then update the [te_Blog_Posts].PostImageUrl column to reflect the new location.