Your session has timed-out

Did anyone encounter this error when connecting to the CS Web services: "Your session has timed-out"

I ve got this error when connecting from a client to the CS Web services hosted on a machine, i did the same tests on another environment with the same web.config file for the web services, and it worked well !!

what could be the problem?

Find more posts tagged with

Comments

Guy_Pomerleau

When we saw that error, it was related to authentication issue: IWA vs livelink

Abdul_Rahman_El_Habboub

I can do the authentication with no errors, I am only getting the error for DocumentManagement web service.

I think it may be an IIS issue, the web.config is the same for both environments...

Abdul_Rahman_El_Habboub

it happens when you have a fresh version of CS 10 update 7

it you upgrade from 6 to 7, it works normally.

Carsten_Kulms

It could be the authentication cookie expiration setting; see section "Authenticating the Client" athttps://knowledge.opentext.com/knowledge/cs.dll/fetch/2001/15080935/-15106263/15106294/16376487/17990637/17990649/17990650/18047148/clientguide.htmlandhttps://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=22390359&objAction=viewincontainer&ShowReplyEntry=22399290#forum_topic_22399290See also Open Text Content Server: Administrator Online Help / Server Configuration / Configuring Server Parameters and Settings / Configuring Security Parameters / Authentication Cookie Configuration / Cookie Authentication Information --> paragraph starting "You can also set authentication cookies to expire..."

Abdul_Rahman_El_Habboub

I have the same settings for the two scenarios...

as i mentioned, it only happens when you have a fresh installation of update 7

if you update 7 after 6, everything works well...

Nicole_Davis

Hi Abdel,

At this point, I would suggest that you open a ticket with OT support in order to best troubleshoot your issues.

Please let me know if you need any assistance with this.

Thanks,

Nicole

musiala

Quoted ahaboub@mgs-tech.com on 2012-09-19 14:07:

I have the same settings for the two scenarios...

as i mentioned, it only happens when you have a fresh installation of update 7

if you update 7 after 6, everything works well...

Hi, I am having the same issue with OTCS 10 fresh install. Do you have a resolution for this?

Thanks

Abdul_Rahman_El_Habboub

Quoted musi.ala@erissolutions.ca on 2012-09-24 11:08:

Quoted ahaboub@mgs-tech.com on 2012-09-19 14:07:

I have the same settings for the two scenarios...

as i mentioned, it only happens when you have a fresh installation of update 7

if you update 7 after 6, everything works well...

Hi, I am having the same issue with OTCS 10 fresh install. Do you have a resolution for this?

Thanks

yes, as i mentioned, it worked by installing the update 6

if you want the 7, install the 6 first then go to the 7, that is what i did

Vanderpoel_Rob

This was a timely post as I've just been having this problem as well.

Here's my experience. I've had this and now replicated it in my VM image which was installed at Update 3 and is now at update 5.

Basically the key is in two areas. One is the post above from ckulms@opentext.com with regard to Authentication Cookie Configuration. The other is the following from the Release Notes:

“Authentication cookies are not updated for LAPI/CSAPI/CWS calls the same way they are done with the UI. Instances with LAPI integrations will have to disable cookie expiration; (LPAD-22520)”

The default value is Expire 30 minutes after last request. Except that, because of LPAD-22520, it expires 30 minutes after authentication, whether you’ve been busy or not. It was easy to verify. I just changed it to 5 minutes and ran my web service client task till it failed after 5 minutes.

The issue was first reported in production and I couldn’t replicated it in my VM. They were saying they need to restart the my client app after about half an hour but I couldn’t reproduce it, even after an hour or two. After reading this topic I checked my settings and my authentication cookie was set to never expire. The production system is set to the default 30 minutes. Changed mine to 5 minutes and bingo, my web service client failed after 5 minutes with a session timeout! Of course, the web client dropped out after 5 minutes of inactivity as well.

Finally, to keep you on your toes, this is from OT’s App Note “Content Server and Configure Security Parameters Explained”

“IMPORTANT:

The online help correctly states that the Log-in Cookie Expiration Date has a default value of Never Expire.

The Cookie Authentication Information, however, has a default value of Expire 30 minutes after last request.

The user help information under the * Cookie Authentication Information bullet item (3rd paragraph) says that the default is Never Expire, but this is not correct; the default is Expire 30 minutes after last request.

Reference: LPAD-23720 “

Cheers

Rob

Ferdinand Prantl

I wonder why you don't anticipate cookie expiration and don't refresh it when the configured time span is exeeded.

--- Ferda

Vanderpoel_Rob

Well I only found out yesterday that was my problem :-) . No doubt this would be best practice but I'm still a relative newbie when it comes to CS web services.

I guess some people may not have that option. In my case it's going to be easier to change the settings on a couple of servers than roll out a new version of the desktop module (assuming changing the setting is acceptable to the customer).

However, I do plan to include it in the next upgrade of the client module.

BTW, for those who want to do this see https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=22390359&objAction=viewincontainer&ShowReplyEntry=22399290: "Also, if you are using CS 10 there is a method in the Authentication service to get the token's expiration date, Authentication.GetSessionExpirationDate()"

Cheers

Rob

Kyle_Swidrovich

One possible solution is wherever you pass a token into a web service method, replace that with a call to a helper function you write that handles refreshing the token if necessary.

Vanderpoel_Rob

Sounds like a great idea, thanks

From: eLink Entry: Content Web Services Forum [mailto:otdncontentwebservices971forum@elinkkc.opentext.com]
Sent: Wednesday, 26 September 2012 3:06 p.m.
To: eLink Recipient
Subject: RE RE Your session has timed-out 2 2

RE RE Your session has timed-out 2 2

Posted by kswidrov@opentext.com (Swidrovich, Kyle) On 09-25-2012 23:05

One possible solution is wherever you pass a token into a web service method, replace that with a call to a helper function you write that handles refreshing the token if necessary.

[To post a comment, use the normal reply function]
Topic:	Your session has timed-out
Forum:	Content Web Services Forum
Content Server:	Knowledge Center

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

rahulsingh81

I am facing this very issue.Tokens are getting expired.

Can you please guide on : How to "handles refreshing the token"....very new to CS webservices so tough to implement.

Quoted Kyle Swidrovich on 2013-10-26 00:26:

One possible solution is wherever you pass a token into a web service method, replace that with a call to a helper function you write that handles refreshing the token if necessary.

Jason_Smith

A timely question. There have been a few issues dealing with token expiration that have been resolved for the next Content Server update (update 13, releasing in December).

The major highlight with this release (at least for CWS) is a new RefreshToken() method that will generate a new authentication token given a currently valid one.

The basic logic to handle refreshing a token would look something like:

1) First login with username/password.

2) Get the time the initial authentication token is going to expire using the Authentication.GetSessionExpirationDate() method.

3) When necessary "refresh" the token. Currently you have to reauthenticate to do this as you would have in the first place like in (1) above (ie. using your username and password again). With update 13 you will be able to take adavantage of the new RefreshToken() method that will no longer require you to have to pass in your username / password again and you can just generate a new authentication token using your current token (provided it hasn't expired already).

One other thing I came across recently is if you have various components deployed on different machines in different timezones. When calculating when your current token will expire, you will want to compare against the local time of the Content Server instance (not necessarily the local time of the machine your app is running on using Date.Now()). To get this time you can use the AdminService.GetServerInfo() method.

Hope this helps.

Kyle_Swidrovich

Refreshing the token = reauthenticating with the username/password.

AlexGerasimov

The example of refreshing your token:

private DateTime? expDate = authService.GetSessionExpirationDate();

        /// <summary>
        /// Get a new session token if the current session is about to expire
        /// </summary>
        /// <param name="authService"></param>
        /// <param name="otAuth"></param>
        private void CheckExpiredSession(
                Authentication authService,
                OTAuthentication otAuth,
                DocumentManagement docService
        {
            Application.DoEvents();
            DateTime curTime = DateTime.Now;
            if ((expDate <= curTime) && (authService != null) && (otAuth != null))
            {
                String token = authService.AuthenticateUser("user", "password");
                Console.Write("Token is received ");
                otAuth.AuthenticationToken = token;
                authService.OTAuthenticationValue.AuthenticationToken = token;
                if (docService != null)
                    docService.OTAuthenticationValue.AuthenticationToken = token;
                expDate = authService.GetSessionExpirationDate();
            }
        }