CUNY Academic Commons

Boone Gorges wrote in #note-2:

I'll need some clarity on what "clicking the link" means.

- When I view the Media Library at https://w25urbansoc.commons.gc.cuny.edu/wp-admin/upload.php, I can see the images I'd expect
- When I view the most recently uploaded PDF in the media library, I see the preview https://w25urbansoc.commons.gc.cuny.edu/wp-admin/upload.php?item=2297
- When I use the URL provided on that Media Library page, I can access the file: https://s3.amazonaws.com/files.commons.gc.cuny.edu/wp-content/blogs.dir/36692/files/2025/01/module-7-Harvey.pdf?X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAZUO33UBRWHMWHNJB%2F20250121%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20250121T181314Z&X-Amz-SignedHeaders=host&X-Amz-Expires=21600&X-Amz-Signature=92e870e16ca93c34a4b6f944a35a3096a6aa750f31f964197a6955472bcada56

What's probably happening is that the user is creating a link to the PDF in such a way that the filename doesn't have these necessary privacy-related parameters (the site is not public, so the files must be accessed at these special URLs). As such, I'll need to know exactly how the user is trying to access the PDF, the URL of the page where a link is embedded, etc.

I sent Boone's message above to the user requesting more info. User response below. "Your email" below refers to the comment above.

I have clicked in the three links in your email from earlier this afternoon. The first two links worked perfectly for me (link to the media library, and link to the preview of the PDF on the media library).

However, the third link you have opens the same error page. See screenshot below my email.

I am currently logged in to the course website, so I should have permission to view the pdf.

To reply to your request, the URLs of the pages where the links are embedded:

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-2/2-readings/

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-3/3-readings/

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-4/4-readings/

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-5/5-readings/

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-6/6-readings/

https://w25urbansoc.commons.gc.cuny.edu/week-by-week/module-7/7-readings/

each time the links are in a green box, white font, “click here to access the article/chapter”

Also, I should add that when the students initially alerted me that this was happening, I checked all the links and replaced them, and it worked for a couple of hours (maybe a day?) but then the error messages started to appear again. Same with some of the pictures.

Thanks for the clarification. This helped me to track down the issue.

Since our migration to Reclaim, uploaded items like PDFs are stored in S3 rather than directly on our server. This means we've adopted a new method for protecting files on private sites. See #21383. The new method involves the use of "signed URLs", which are secret and have a relatively short expiration date. As part of this migration, I wrote a tool that swaps out URLs in post content to ensure that private URLs would always be up-to-date. But I neglected one case, specifically, where already-signed URLs are stored in the post content. As such, the URLs that appeared in the post content were expired, and the files not accessible.

I've fixed this in https://github.com/cuny-academic-commons/cac/commit/f60272caad81b7a328e100d7f936672b9af57ddc. You should be able to verify by looking at the posts in question and clicking the PDF links.

However, the third link you have opens the same error page. See screenshot below my email.

It's worth clarifying that this is a change in the way that private files worked. It used to be the case that you could view a file on a private site at the same URL as when the site was public. When you requested the file, WordPress would detect whether you had permission to view it. This was nice, but it meant that WP had to be loaded for every asset request. Now, uploads on private sites are not accessible at the same URLs as when the site is public. The file can be downloaded only by those who have the signed URL, and the signed URLs are only available to visitors who have access to the post content. However, we set an expiration on these URLs so that people can't pass them around and violate the privacy of the files.

I don't expect this to be a problem in the vast majority of cases, since these files are almost always accessed via the WP frontend or dashboard. But if we get many further reports, I have some ideas for how we might build an even more arcane system in the future that mitigates the inconvenience. (Note to self: on private sites, we'd filter post content to show WP URLs like blogs.dir; then we'd put .htaccess in those dirs on the physical server that drove traffic to a script that checked for access and then rewrite the URLs to the signed S3 URLs.)

Laurie, sorry this is so complicated, but hopefully you can (a) verify that it's working, and (b) distill some version of an explanation for the user.

I'm going to close this ticket because the fix was included in the 2.5.1 release. But if you hear back from the reporter that things are still not working right, please let me know.