Business Server Pages [Read-only]
Page tree
Skip to end of metadata
Go to start of metadata

In the BSP environment a number of cookies can be used for different aspects. The two cookies sap-contextid and MYSAPSSO2 are often used and very important. This guide describes steps to troubleshoot cookie failure.

  • sap-contextid: This cookie contains a session id. Once we have a cookie failure, it will happen that the session id for the existing session is not returned to the server, causing the server to open a new session per HTTP round-trip. The first place where this can be observed would be in transaction SM04.
  • MYSAPSSO2: This cookie contains the Single Sign-On data for the specific user. If it fails, then some times of applications, such as the BSP SYSTEM logon application, will fail to work. Also, it can cause the browser to bring a new authentication popup asking for name and password.

Problems in Naming of Host or Domain

One of the simplest reasons why the browser can refuse to accept a cookie, is because either the host or domain name of the server does not meet the standard Naming Requirements for Hostnames and Domains. Please read first through the referenced section to ensure that neiter the hostname itself, nor the domain, contains any illegal characters (typically a _-character) and that the domain has the minimum number of required segments.

MYSAPSSO2 Failure in HTTP Mode

One of the problems we have seen a few times, is that the server will set a MYSAPSSO2 cookie, and that with the next HTTP request, the cookie is NOT send back to the server. The domain, path and expiry data for the cookie is completely valid. Let us quickly look at a HTTP trace of this failure.

GET /sap/bc/bsp/sap/system/sso2test.htm?sap-user=uuu&sap-password=ppp HTTP/1.1
 Accept: */*
 Host: abc.klm.xyz.com:8080
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

 HTTP/1.1 302 Moved temporarily
 Content-Type: text/html; charset=iso-8859-1
 Location: /sap(bD1k==)/bc/bsp/sap/system/sso2test.htm?sap-user=uuu&sap-password=ppp
 Server: SAP Web Application Server (1.0;620)
 Set-Cookie: MYSAPSSO2=AjEx...; path=/; domain=abc.klm.xyz.com; secure


 GET /sap(bD1k==)/bc/bsp/sap/system/sso2test.htm?sap-user=uuu&sap-password=ppp HTTP/1.1
 Accept: */*
 Host: abc.klm.xyz.com:8080
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

 HTTP/1.1 200 OK
 Content-Length: 2200
 Content-Type: text/html; charset=iso-8859-1
 Server: SAP Web Application Server (1.0;620)
 Set-Cookie: MYSAPSSO2=AjEx...; path=/; domain=abc.klm.xyz.com; secure


 GET /bc/bsp/sap/system/sso2test.htm?pass2=true HTTP/1.1
 Accept: */*
 Host: abc.klm.xyz.com:8080
 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

 HTTP/1.1 401 Unauthorized
 Content-Length: 41
 Content-Type: text/html; charset=iso-8859-1
 Server: SAP Web Application Server (1.0;620)

What we observe is that with each HTTP response, a MYSAPSSO2 cookie is set for the path /, with the matching domain. However, on each following HTTP request to the server, the cookie is not returned back to the server. On the last request we get a complete authentication failure (HTTP return 401 from server), because no user name and password is available in the URL and because the MYSAPSSO2 cookie went missing in action.

The reason for this specific error is that the MYSAPSSO2 cookie is set with the secure flag. What this tells the browser, is that this cookie can only be returned to the server on a HTTPS connection! As we had a HTTP url (not HTTPS), the cookie was each time stored by the browser, but not returned to the server.

This problem can at the simplest be verified with a HTTP trace. The alternative would be to show that the tests work in HTTPS mode, but fail in HTTP mode (be careful, aspects such as X.509 certificates can skew the results of this specific test).

Question: Why did the server set the MYSAPSSO2 cookie with the additional secure flag?
Answer: This is controlled by the profile parameter login/ticket_only_by_https. If set, the secure flag is added, making the MYSAPSSO2 cookie fail in HTTP mode. (One could argue that a secure cookie should not be set while running in HTTP mode, but that is how it works at the moment.)

Cookie Jar Full?

Another problem we observe seldomly is that of a full cookie jar. Effectively, most browsers can only accept a maximum of 20 cookies. Especially with a long running BSP application that keep referencing another BSP application (for example F4 help), this problem can occur. Each time that the new application is started, it might also set cookies. If these cookies are not cleaned up, then the cookies will accumulate, quickly reaching the limit of 20 cookies. At that moment, older cookies are dropped, which will usually hit the first set cookies (sap-contextid and MYSAPSSO2), causing again a complete failure. In cases of long running BSP applications, take a HTTP trace, and count all the Set-Cookie headers. Ensure that cookies are deleted again when not required.

Very important: in HTTP there is no technique to explicitly delete a cookie. It can only be set new with an expiry date that is in the past. However, this is again a new cookie that is first placed into the cookie jar, optionally kicking another cookie out, before the expiry date is taken into consideration. So an excessive setting of expired cookies can also flood-fill the cookie jar, causing important cookies to be dropped. In the HTTP trace count all Set-Cookie headers, even if expired, first as a real cookie.

Another important aspect is that a cookie can only be deleted by setting it new with exactly the same path as previously set. This path string must match in case and in length (100% character match). Even the difference of a trailing /-character will result in the old cookie not been deleted, stuffing the cookie jar until it spills.

References