My dev ondemand server records this when the session opens:
129.22.118.159 - mrd20 [16/Jun/2025:14:53:16 -0400] “GET /pun/sys/dashboard/assets/xdmod-8fd70dfb5d5d6aba8219556e3033f72fd553212a0989bd9de02c7429faf835aa.js HTTP/1.1” 200 188883 “Login” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:139.0) Gecko/20100101 Firefox/139.0”
I don’t find any other log files recording the name of the xdmod dev server.
On the xdmod dev server, this appears in ../httpd/apache_access.log
129.22.118.159 - - [16/Jun/2025:15:12:32 -0400] “GET / HTTP/1.1” 200 15195 “https://ondemand01.case.edu/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:139.0) Gecko/20100101 Firefox/139.0”
This lacks anything consistent with an authentication token.
What is supposed to pass forth and back between the ood and xdmod servers when the xdmod widgets are configured for use in the ondemand dashboard? And in what files should I see the record of this auth token passing back and forth?
Thanks
ps As always, i’m happy to be corrected whenever I’m not thinking correctly about something
This is the flow below. You interact with these servers (along with your Identity Provider), but they don’t interact with each other directly.
- You request the OnDemand page
- You’re served the OnDemand page
- javascript from the OnDemand page issues some
fetch calls to your XDMoD
- XDMoD responds to your
fetch calls, likely redirecting you to your Identity provider.
- You’re Identity provider responds, and if everything went well, redirects back to XDMoD to provide the requested data.
Here’s a snippet of my network tab in my browser when I login to our machines. The request I’ve highlighted is the first in the flow. It is a request from my laptop to our XDMoD instance. You can see after a few XDMoD requests, it starts routing me to my IDP.
This all works of of what HTTP calls Cross Origin Resource Sharing or CORS. That’s the basic functionality of how any given internet site can be made up of many other sites (think about how ads are injected into a webpage, not from the original web page, but from some other domain. it works through CORS).
These credentials are passed as cookies (which are HTTP headers). Setting httpd logs up to very high levels of logging may log headers, but I’m not sure. In any case, that’s why you don’t see them - they’re headers which httpd isn’t logging, at least by default.
Thanks Jeff! This will foster useful troubleshooting and discussions locally. Will report back on our findings.
Best
~ Em
Here’s the network tab output from my ondemand server, which lacks any entries from xdmod
So I must be missing important elements from the ondemand configuration, yes?
So, manual changes to xdmod portal_settings.ini are seemingly fragile. I’d previously included the ‘domains’ statement manually, and discovered today that it was likely changed and not restored during our upgrade from 10.5 to 11.0.
Now ‘domains’ is set in the portal_settings.ini:
domains = “https://ondemand01.case.edu”
and the frame ancestors:
frame_ancestors: https://*.case.edu ‘self’
After updating ondemand.yml to adjust dashboard to present both xdmod widgets, I’m now seeing 500 codes reported in the network: signin to xdmod messages in the widget windows. The session, however, is signed in through Case SSO to xdmod.
Perhaps this is where xdmod:SimpleSAML and ondemand:CAS are unable to communicate? Or perhaps there is another root cause at play?
Best
