CUNY Academic Commons

It appears that requests from the Commons to the gethandshake.com URLs (like https://huntercuny.joinhandshake.com/external_feeds/22199/public.rss?token=mvGP52tz9dcrPlLLUOuKd3sAMAV-viV-qWZfG0AxEWU7n2I033VoNg) are returning a 403 Forbidden error. This suggests to me that gethandshake.com has blacklisted or otherwise blocked the Commons. There's many different reasons why this might happen, but generally it's due to too many requests taking place.

I'd recommend that Jane, or whoever's responsible for talking to the folks at gethandshake.com, to file a ticket asking whether they can get more information about why requests from *.commons.gc.cuny.edu (15.204.146.102) are being blocked.

Jane replies:

Here is the response I received from Handshake. Could you please let me know what our next steps could be:

I can confirm that we don’t restrict access to schools based on IP addresses, and there would be no way on our end to unblock anything. That said, it’s possible that our IPs may need to be unblocked on your side. You can find the full list of our IP addresses in the Email Delivery: Unblocking Handshake Email.

Looking at the errors in your screenshot, it seems these are the feeds involved:
Clinical Care Events
https://huntercuny.joinhandshake.com/external_feeds/22199/public.rss?token=mvGP52tz9dcrPlLLUOuKd3sAMAV-viV-qWZfG0AxEWU7n2I033VoNg
Career Fairs
https://huntercuny.joinhandshake.com/external_feeds/22507/public.rss?token=MD0AU-Va2RFGPaK7vErVPpUCvgzzZQHAPJtcT20qwQwt7O_p6IT90A

It looks like the Career Fairs feed currently doesn’t have any active results, which might explain why it’s not displaying as expected.
As for the Clinical Care Events feed, I didn’t encounter any errors when opening it in a browser. It seems the issue might be specific to how the feed is being processed in your RSS widget. One thing to check: I noticed there are emojis in the description of the second event in the feed results, titled “Exploring Through Play – Nurturing Growth and Healing in Children.” Do you happen to know if your RSS widget supports emojis? That could potentially be causing issues.

Let us know what you find, or if we can help dig into this further!

It's good that the Handshake folks responded so quickly, but I'm afraid that their diagnosis isn't quite right. We are getting 403 errors, indicating that our requests are being flagged as "forbidden". This is almost certainly happening on their end, probably in their web-application firewall or perhaps in their server security rules. Specifically, I'm also able to access the feed URLs from a personal machine/IP, but when I run the same commands from the WordPress production site, the requests are rejected:

$ ifconfig | grep 15.204
        inet 15.204.146.102  netmask 255.255.255.255  broadcast 15.204.146.102  destination 15.204.146.102

$ wget https://huntercuny.joinhandshake.com/external_feeds/22199/public.rss?token=mvGP52tz9dcrPlLLUOuKd3sAMAV-viV-qWZfG0AxEWU7n2I033VoNg
--2025-04-28 21:47:59--  https://huntercuny.joinhandshake.com/external_feeds/22199/public.rss?token=mvGP52tz9dcrPlLLUOuKd3sAMAV-viV-qWZfG0AxEWU7n2I033VoNg
Resolving huntercuny.joinhandshake.com (huntercuny.joinhandshake.com)... 34.160.45.135
Connecting to huntercuny.joinhandshake.com (huntercuny.joinhandshake.com)|34.160.45.135|:443... connected.
HTTP request sent, awaiting response... 403 Forbidden
2025-04-28 21:47:59 ERROR 403: Forbidden.

This shows that the connection is completing, but the server is rejecting the request.

I didn't get a full update, but this is resolved. I can ask more if you'd like.

Alas, it went down again and she wrote to them:

Here is what I got back from Handshake regarding the feeds issue:

“I wonder if this means that the IP Address attempting to access the public URL for these feeds is appearing suspicious. Could you confirm which IP addresses Wordpress, or Feedzy or whoever is accessing our link, is using to access it?

We don't block IP Addresses ourselves but knowing where the request is coming from might help me point our engineers in the right direction.”

Could you please let me know the IP address?

Connections will likely come from 15.204.146.102 and similar addresses.

Jane writes:
Handshake’s response in case it’s helpful for the Dev Team to determine the issue:

“Let me look further into this, but we shouldn't be receiving any connection form your side. How the feed reader works is it takes the public link which is an xml file of the jobs, events, ... and the feed reader ingests and transforms the XML file into a readable format that you can put on your website.

I will look into the feed links themselves and test a few of them with some generic feed readers. If I can't find anything I will reach back out and see if we can schedule a zoom call with your IT team.”

Thanks for sharing this. I'm not really sure what's meant by "we shouldn't be receiving any connection from your side". We are entering an RSS (ie XML) URL into the Feedzy plugin. Then plugin then uses wp_remote_get() (cURL under the hood) to fetch this RSS file. This means that the WP application on our server is making a cURL request to https://huntercuny.joinhandshake.com/external_feeds/22199/public.rss?token=mvGP52tz9dcrPlLLUOuKd3sAMAV-viV-qWZfG0AxEWU7n2I033VoNg. This is certainly a "connection". Perhaps the tech means that we're not making any sort of authenticated API request. But these requests are indeed triggering 403 response from the Handshake server, even though the XML file is "public". As noted earlier, this suggests that it's a problem at the WAF or CDN or something similar, based on rate-limiting or other such triggers. Anyway, I'm leaving this note here as an aide-mémoire in case we do ever have to have that conversation.

And more:

I have another update from Kai from Handshake:

“I have checked the feeds and they are working just fine with my feed reader. Some of the feeds are empty so not sure if that is the issue. I can meet with your IT team over zoom to further discuss this, but this seems more like an issue on their end so I can't promise any solutions if they aren't familiar with the way they set it up.

· https://calendly.com/d/cm5v-mcc-8g9/30min?share_attribution=single_use_link

Kai”

Thanks for passing this along. The message indicates that there's not a really clear understanding of the problem we're experiencing. As long as it doesn't turn into a broader issue, I think we can refrain from scheduling a call.

The user says the issue is not resolved.