Resized Image REST API Broken in 10.3.2.7882?

That isn't a REST API, its not meant to be called directly because it relies on you being signed in to the community.  In 11 that url would respect API authentication but not earlier, and this would have always been the case.  The REST API for files is https://community.telligent.com/community/10/w/api-documentation/61480/show-cfs-rest-endpoint.

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.

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.

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.