Application dumps after over 8 hours

[Former Member]

Hi all,

My Web dynpro (ABAP) application has dumped when it run over 8 hours. I checked the log, the error involves to SSO, although my system doesn't apply SSO at all. The parameter login/create_sso2_ticket = 0.

I used ST22 tcode to check, the error relates with OBJECTS_OBJREF_NOT_ASSIGNED and do_not_use_sso2_ticket.

Before the dumps starts it throws this errro: N *** ERROR => HMskiCheckValidity failed. http://ssoxxkrn.c 1076.

Please give me your advice.

[Former Member]

Hi

work with basis to find if additional settings are done in "default.PFL"

for the parameter login/create_sso2_ticket

[mvoros]

Hi,

you just don't know that your systems uses SSO :-). SSO is usually used even if you have just one system. When user logs on to the first web dynpro application he gets a ticket. This ticket is then used for all other authentications (e.g. you navigate to different web dynpro application). By default the expiration time is set to 8 hours. It can be changed with parameter login/ticket_expiration_time. Don't forget that the change of this value has some security implications.

Cheers

[Former Member]

Martin,

You mean to say this parameter will work even if single sign on is not configured?

Is it not that SSO is configured in a SAP system and validity(time period) takes effect only when SSO ticket is generated?

[mvoros]

No, this parameter says only how long is SSO ticket valid. If you set parameter to login/create_sso2_ticket to non-zero value then system generates a SSO ticket. This ticket is digitally signed and is valid only limited time (by default 8 hours).

What I meant is that it's normal to use SSO even if you have just one system. Usually, it's requested by users if you have multiple web dynpro applications. You have the following basic options for authentication for web dynpro applications.

1) Fields Authentication

2) SSO Authentication

3) Basic Authentication (aka HTTP)

The problem with option one is that you have to re-authenticate against each web dynpro application which is seriously annoying. The problem with option 3 is that you don't get a nice logon screen. You get an ugly popup for HTTP authentication and trust me, users don't like it. Usually, you choose to use SSO even if you have just one system.

Cheers

[Former Member]

Thank Martin,

Your advice is very useful. I have read SSO yesterday, and found that web dynpro uses cookie to keep information about logon ticket as: user id, validity period, issuing system, .... But it was strange when I disabled (block) my browser's cookie, my web dynpro application still worked well, I don't know why. Could you please explain this?

Thank you,

Ken.

[mvoros]

Hi,

SSO ticket is represented by browser cookie with name MYSAPSSO2. As I wrote in my previous post there are multiple options how you can authenticate against web dynpro applications. By default the standard logon procedure is used. You can change it for each web dynpro application in transaction SICF. The standard logon procedure means that after successful log on the system generates a SSO ticket. This ticket will be used for the following authentications. The next authentication will happen only if you navigate to different service from SICF (e.g. another web dynpro application). If you stay within one web dynpro application then you won't have to re-authenticate. So web dynpro application works even if you don't accept cookies. You just have to re-authenticate against each web dynpro application again and again.

Cheers

[Former Member]

Thank Martin,

I got it. And you can see the SAP Note 1405432, this involves my problem.