We're currently experiencing some strange behaviours with regards to the SAP MYSAPSSO2 cookie that can be retrieved from the headers via a HTTPOnly call to a SAP authorization portal. I'm hoping someone can pinpoint me to what we're overlooking. Something tells me that the CloudFoundry environment where the application runs could be the cause of these problems. Scenario The application is running on CloudFoundry and the application runs on Mendix 6.5.1. We have a Java action that was developed by someone in the team that opens a connection to the Portal (https://domain.ext/irj/portal) and processes the response headers after sending a base64 encoded (username:password) Authorization header (Authorization : Basic <base64>). The contents of the code look as follows: String indicator = "MYSAPSSO2="; String header = "set-cookie"; URL url = new URL(portalURL); HttpURLConnection httpURLConnection = (HttpURLConnection)url.openConnection(); String userAndPass = usernameSAP + ":" + passwordSAP; byte[] codepoints = userAndPass.getBytes("UTF-8"); String base64 = new String(new Base64().encode(codepoints)); httpURLConnection.setRequestProperty("Authorization", "Basic " + base64); Map<String, List<String>> map = httpURLConnection.getHeaderFields(); int responseCode = httpURLConnection.getResponseCode(); String responseMessage = httpURLConnection.getResponseMessage(); httpURLConnection.disconnect(); List<String> headerList = map.get(header); for(String entry : headerList) { errorMessage = errorMessage + " " + entry; if(entry.indexOf(indicator) >= 0) { return entry.substring(indicator.length(), entry.indexOf(';')); } } logger.warn("Volledige response: " + errorMessage); logger.warn("HTTP response voor request = " + responseCode + " (" + responseMessage + ")"); return ""; The result should be that the MYSAPSSO2 token is returned by invoking this action. Problem This works as soon as the application is started on CloudFoundry. The problem is that over time (we currently still can't pinpoint whether it's the result of x amount of requests or x amount of time), requesting tokens from the authorization server can result in receiving almost empty headers, of which most importantly is the fact that we receive no MYSAPSSO2 cookie in the header. We are 100% sure the input authentication is correct. In case of a succesful token request, something like below should be received as headers: SESSIONMARKID=<value removed>; Version=1; Path=/ JSESSIONID=<value removed>; Version=1; Path=/ saplb_*=(<value removed>)<value removed>; Version=1; Path=/ PortalAlias=portal; Path=/ MYSAPSSO2=<value removed>; path=/;domain=.<domain>.nl;HttpOnly What we're getting instead after a while is simply one line: Path=/ PortalAlias=portal; Path=/ So to be clear: initially everything works fine, tokens are getting received. Over time, however (think hours/days, but usually within 24 hours), we simply stop receiving tokens whenever a user tries to request one. What's interesting is that I have yet to reproduce this issue on my local machine, which is in fact connected to the client's internal network. I even created a test microflow that simply requests a token 50x with a delay of 5000ms inbetween each call. But ofcourse the main difference between my local machine and the app environment is CloudFoundry. Furthermore, as soon as these problems arise, restaging the CloudFoundry application environment (with the command cf restage <app>) results in the application being able to succesfully 'grab' the headers again. So restaging results in the user receiing the MYSAPSSO2 token again. Has anyone ever encountered anything like this before? Something tells me that it could be a CloudFoundry configuration issue. On the other hand, the fact that restaging the environment results in succesfully obtaining new tokens also has me thinking whether somehow the application got blocked by SAP. All requests for a token (the ones that do succeed and the ones that fail) do give us a HTTP status 200, which would make it seem as if the connection could be made, but the problem would reside on the SAP authorization side.