Custom Request Handler - OTDS Authentication and Cookies Override

Hi Guys,

I created a custom request handler to log in a global user behind the scenes that executes a web Report to display documents on passed in parameters. The global user is authenticated, however the cookie for the current user seems to override the the newly authenticated global user. Is there clean way to bypass or clear the cookie/cache of the current user's machine to allow the global user that is authenticated in the request handler to become the current user? Or should I create a webService instead?

Find more posts tagged with

Comments

eLink User

Couldn't you just use the WebReports "Run As" feature for this?

Check the specific tab for the webreport to define a run as user to execute the webreport as.

Cheers

Ian

Sent from a mobile device

On 13 May 2016, at 21:01, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

eLink : Custom Request Handler - OTDS Authentication and Cookies Override
Custom Request Handler - OTDS Authentication and Cookies Override Posted by Lee-Curbean, Stacey On 05/13/2016 03:55 PM

Hi Guys,I created a custom request handler to log in a global user behind the scenes that executes a web Report to display documents on passed in parameters. The global user is authenticated, however the cookie for the current user seems to override the the newly authenticated global user. Is there clean way to bypass or clear the cookie/cache of the current user's machine to allow the global user that is authenticated in the request handler to become the current user? Or should I create a webService instead?
[To post a comment, use the normal reply function]
Forum: Content Server Development Forum
Content Server: Knowledge Center

Stacy Lee-Curbean

Hi! Thanks for your response. When the report is configured to run as the specific user, the footer still shows the current user of the system who is authenticated via OTDS (cookies). So, I am uncertain if this will work for users who are accessing the request handler externally that don't have CS accounts; hence the reason for authenticating a global user within the request handler. However, the OTDS single sign on and cookies seem to override the global user's authentication.

John Simon

Stacey,

I have not seen OTDS (yet) so not much help on that front. RequestHandlers are "normally" orphaned from WEBLL but they don't have to be! You can orphan from WEBDSP:WebDsp Root:RequestHandler and bypass authentication all together. Obviously you don't get any of the benefits that WEBLL adds to the request handler (like a prgctx for example) so you would have to work around that.

You don't see this method used very often (if ever) so not really sure how OT feels about it...

Cheers...

eLink User

I could not resist John/Stacey,

The new OTDS authentication kind of works like this.If you are domain authenticated(we call them by many names SSO, Kerberos Token) etc then the livelink webserver will pass your domain name(REMOTE_USER) and it will forward to OTDS and OTDS will do the magic hitherto provided by the webserver. You can very well use the old webserver auth(IWA) method as well.Regardless when the call comes back to the application livelink there is a auth token.Livelink oscript will decrypt that back to 'simonjw' or 'knair' or 'staceyl' and voila if you guys are in LL you are in.Now all the context mechanism is with your 'PrgCtx' so you see what you are supposed to see.

Now comes the difficult part.I think Stacey wants to run the request as someone else.Hence the suggestion of "Run As".From the suggestion it looks like Stacey has to do a "impersonate" which is allowed by the application .We do it all the time in lapi and soap.Hint GimmeaprgCtx...

Now the way I think it could be done is provided the "RunAs" is not jiving.

The original requestor has "SA" on his/her profile,this is the precondition.(in oscript you probably can get away without it)
Create the user context who has to be impersonated (these are the GimmeAPrgCtx example)
Call the commands as the new user's prgctx if you dont then the DAPICTx is still your original user so you have to do a Dapi.GetNodeByID again.
Destroy this session and any objects immediately after use.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, May 16, 2016 at 7:19 AM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Re Custom Request Handler - OTDS Authentication and Cookies Override Posted bySimon, JohnOn 05/16/2016 08:16 AM

Stacey,I have not seen OTDS (yet) so not much help on that front. RequestHandlers are "normally" orphaned from WEBLL but they don't have to be! You can orphan from WEBDSP:WebDsp Root:RequestHandler and bypass authentication all together. Obviously you don't get any of the benefits that WEBLL adds to the request handler (like a prgctx for example) so you would have to work around that.You don't see this method used very often (if ever) so not really sure how OT feels about it...Cheers...
[To post a comment, use the normal reply function]
Topic: Custom Request Handler - OTDS Authentication and Cookies Override
Forum: Content Server Development Forum
Content Server: Knowledge Center

Greg_Griffiths

I suspect that this behaviour is by design as you would want to show the current user in the footer rather than the user that actually ran the report - as this could be Admin or some other higher powered user, may be worth asking for a Feature Request so that you can show the user in the footer.

If you are going to maek this available for non CS users then I'd check your contracts with OT to ensure you stay on the right side of the licencing model and requirements.