Resized Image REST API Broken in

Community Version:

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?



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

Status Code: 403

  • Hey Michael. Yes, permissions are set correctly and the file is physically there. I see it in this folder: filestorage\communityserver.blogs.components.weblogfiles\00\00\00\00\06

    Looking at permissions directly on the file, the app pool identity has inherited modify access from the filestorage root.

  • In the $core_v2_ui.GetResizedImageHtml widget API, what determines if the src returned uses /resized-image vs /cfs-filesystemfile? The couple of tests I ran with new blog posts seems to always use /cfs-filesystemfile which is working for me.

  • 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:


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


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

  • 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.