nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Getting a valid session for a long running thread

Bill Klish

TeamSite 6.5
Windows 2003

I have written a J2EE app that runs inside of Content Center and is invoked via a CGI task in a workflow. The app eventually gets to a place where it needs to wait for another activity to be completed before it can continue. We were hoping to avoid using external tasks, and have embedded everything within the content center web app.

Here is the issue. At times, the other activity will not be completed in a 24 hour period, so the thread that is running behind the scenes will no longer be authenticated, and will stop working. The only way to reactivate the thread is for the user to start the CGI task again. So, to get a valid session it can be retrieved from a client object from the session, a valid, unexpired session ID, or a username and password. If our session expires we have no way to obtain it...that I can think of...other than to pass a uid/pwd and we absolutely don't want to store all those in an accessible location. so, the question is, do we have to split our application into external tasks, or is there a way to keep our session and this thread running until its complete?

Find more posts tagged with

Comments

Migrateduser

There are a coupe of options -

1. Increase the timeout period of the session to > 24hrs. This can be done in the iw.cfg file.

2. The other option is to use the CSFactory.getClientForTrustedUser() method, in case your CGI task is executed on the same box where TeamSite resides.

I would like to know if you are using CSSDK explicity in your CGI Tasks, or is it that you make redirects to Content Center URLs. If you use CSSDK directly, you can use it with the CSLocalFactory on the same machine as TeamSite. If not, option 2 is not an option for you.

I hope I made myself clear. If not, please feel free to clarify any misunderstanding I have about your use case.

Best Regards,
Narendra

Bill Klish

I don't like option #1, as it will be a system wide change.

Option 2 looks promising, but I remember issues with it that were brought up during a gear up presentation. I don't see that documented inthe current cssdk jars I have with TeamSite 6.5. I assume it is part of service pack 1. I will get that installed.

We are having our CGI tasks be called as servlets/jsps using the cssdk, not as content center urls. We have wrote our own stuff to be called from a workflow.

These servlets/jsps are being added into the content center web application using the customer toolkit, so everything is running on the same server and in the same container.

I am looking at the cssdk 2.5 sp1 documentation and I see the parameters as:

java.lang.String name, (user's name)
java.lang.String role, (user's role)
java.util.Locale locale, (locale)
java.lang.String appContext, (not sure what goes here)
java.lang.String server (assume set this to null or leave blank for same server)

I looked at the CSLocalFactory definition of this method and it has the same parameters as the general cs factory method. I don't see any examples of this new method or documentation on it in the CS SDK 2.5 cookbook, so I am wondering if this is how it works:

CSLocalFactory factory = CSLocalFactory.getFactory(props);
CSClient client = factory.getTrustedClient("user1", "editor", "en-us", (don't know), "");

I just read the release notes and notice this bug:
58708 Permission denied error when creating files if the CSClient object was obtained using getClientForTrustedUser.

This could be problematic. Are there any other gotchas with this approach?

Bowker

The error is avoidable. Depending upon your companies "sensitivity" to file ownership issues.

The bug (58708) was found while trying to create new files after using the getClientForTrustedUser() method. The files are created under the ID of the ID being used for the server. In our case "SYSTEM". Our solution was to change the ID of the server and grant that ID write access everywhere. That ID has a very long pretty much random password that only the domain administrator knows (you have to trust someone, if not yourself).

We're using .getClientForTrustedUser in EVERYTHING we do and have not run into any "show stoppers" except the one speed bump mentioned above.

Dan Bowker
Northern Trust
Web Publishing Technology