So I have 2 VS
VS_A with ASM attached and forwards to VS_B with APM attached
I have written irule for handling CORS request that sits on VS_A
My issue is - I have Jira and Confluence on VS_C but the URI are protected by APM - using OAUTH and VS_B is the OAuth server
so ajax / xhr requests are sent to VS_C but when the OAUth token needs to be refreshed it (VS_C APM) send a 302 to VS_B
My guess is the ATLASSIAN code see a 302 on a xhr/ajax call so it then does a CORS OPTIONS / PreFlight - not sure why it doesn't just call with ORIGIN but
So the OPTIONS call gets send to VS_B - which means its goes to VS_A first to uri /f5-oauth2/v1/authorize
The irule sends back the relevant headers
then the atlassian code does a GET request with ORIGIN Header
/f5-oauth2/v1/authorize then responds with a 302 to /my.policy (this seems strange normal OAuth ops don't do this )
same cycle again
then get call and my.policy send it to /my.log.out.php?errorcode=19
When i test this with our internal ajax code - it just does a js FETCH which turns into a GET and it just work
Now that I have written this I wonder if the error is with /f5-oauth2/v1/authorize as it should have consumed the request !!!
I tested on the internal that does a strange GET with ORIGIN - it goes to the /f5-oauth2/v1/authorize and that does a 302 ... so its not that ... some thing strange going on with APM
I think it seems like you have a complex setup involving multiple Virtual Servers (VS) and the use of irules for handling CORS requests and OAuth authentication. You've described issues with CORS preflight requests, OAuth token refreshing, and unexpected behavior with certain URLs. Use tools like browser developer tools, Fiddler, or Wireshark to inspect the HTTP headers exchanged during the CORS preflight requests, OAuth token refreshing, and other interactions. This can help you identify any unexpected headers or missing configurations. Create controlled test scenarios where you isolate specific components of your setup. For example, test the CORS preflight requests separately from the OAuth token refreshing to identify which step is causing the unexpected behavior.