Session time in Content Server - how does it work?

Rob Hooijmaijers

When you create a new session with Content Server using API (either using the 'auth' API or an 'Impersonate User' API), a ticket is created. This ticket is valid for a specific period of time (I think 30 minutes). Two questions:

• Suppose you use this ticket directly after you have created it. And then you don't use it for 10 minutes. The ticket can then be used for another 20 minutes before it expires. After these 10 minutes, the ticket is used again to execute a search (for example). What happens then to the remaining time that the ticket is valid? Is it still valid for 20 minutes, or is the time that it is valid set back to 30 minutes?
• Is it possible to cancel/delete a ticket or declare it invalid using API?

Kind regards,

Rob

Appu Nair

The internal CS mechanisms have many ways of handling sessions and are lookable/understandable using Oscript. However if your question is to handle sessions so that an api call does not get rejected OT has advised REST API developers to issue a REST API call after the initial auth call and then to handle the chaining of authentication but taking the Ticket that comes back with each response.

I see in newest CS there are ways of revoking the ticket as I have seen a logout warning saying "click here to stay in session" .If you do not see as part of the auth rest api then I would ask OT or even see if the warnings one is getting is part of the OTDS application.

The reason I am not telling you internal mechanisms is because they can all change because that is not a public api:)

Rob Hooijmaijers

Thank you Appu. So the best way forward is to do the initial auth call via REST API. That gets you an OTDS ticket. That ticket can be used to execute the next API (for example: search documents), which returns an OTCS ticket. That OTCS ticket can then be used for the next API Call etc.

As long as you keep on executing API calls within half an hour, there will be no problem with expired sessions.

The only question that remains that is this: how to handle expired sessions?

• Do you check if an OTCS ticket is still valid before executing an API call?
• Or do you execute an API call and check whether the API returns a message like 'Session expired', after which you obtain a new OTDS ticket and proceed as described above?

What is your recommendation?

Appu Nair

I do not specifically know REST implementation but REST is akin to a glorified Request Handler(RH) so it inherits a lot of code from that .In the CS GUI if someone had left their browser open for a day so that it probably ticked off everything in the Security Parameters section of CS

If you are looking for no authentication trouble I would use the first setting (Client IP)otherwise depending on your cluster a cookie issued for one server may not gain entry into another .I would probably put that to 1 minute and try your tests .In the GUI when the authentication code figures out the cookie is expired the code will silently redirect it to OTDS for login so if SSO is configured it would yield a OTDSSSO* and we are back with a LLCookie with 1 minute. So probably in REST also the same code is in play, the only part I wouldn't know is if the redirection business is valid .Since it deals in esoteric auth mechanisms a ticket with someone who knows the auth cycle in OT(hopefully the person knows CS and OTDS) maybe your best bet rather than rely on public forum info where we are at best guessing....Who knows your ticket may garner enough interest for OT to put out a KB!

my $0.02

Rob Hooijmaijers

Hi Appu, I don't know either if the silent redirect also works in REST. To illustrate this, in Postman I see the following: suppose the lifetime of an OTCS ticket is set to 30 minutes. And suppose that I have made an API call 32 minutes ago, which gave me an OTCS ticket. When I am going to execute a new API call now (32 minutes after I got the OTCS ticket), Postman shows the following message: '{"error": "Session expired"}'.

So the only way forward I see in this situation, is to catch this return value in the code, execute an auth API call to get a new ticket, and the re-attempt to execute the API call that gave you the 'Session expired' message.

Do you agree?

I agree with you that a KB from OT would be very helpful here :-)

Appu Nair

I bet if you were to send a OTDSTicket every time and not worry about getting the OTCSTicket you would need no additional code...

Rob Hooijmaijers

But an OTDS ticket can expire as well. Or do you mean 'create a new OTDS ticket for every API call'?

Rob Hooijmaijers

Just another question about these OTCS tickets. By using a newly generated OTCS ticket after each API call, the situation will arise (situation 1) where within a short span of time several OTCS tickets are created for one user. Now let's compare this to a situation where only 1 OTCS ticket is created per user (situation 2).

In general, you can then reason, that when there are large amounts of tickets (situation 1), the chance of someone getting their hands on one OTCS ticket, and then getting unauthorized access to Content Server, is considerable bigger. Solely because there a lot more valid OTCS tickets available.

The chance of that happening in situation 2 (with far fewer tickets) is significantly smaller.

So my question is: are these OTCS tickets shielded off for outside users (hackers)? Or, should the developers of the user interface of the customer, take counter measures to prevent hackers from obtaining an OTCS ticket (use https for example) in the first place, and prevent hackers from using an OTCS ticket via for example a URL parameter?