Using a temporary Admin PrgCtx - and destroying it

I'm having a problem when I have a discrete function that creates an Admin PrgCtx and then destroys it ... if I'm logged in as Admin.function someFunction()object AdminPrgCx = createAdminPrgCtx()...... use AdminPrgCtx...AdminPrgCtx = destroyAdminPrgCtx(AdminPrgCtx) // returns Undefined after doing a .Delete()endAs far as I can tell this should be safe and scoped locally. However, the PrgCtx of the calling function is now Undefined - only when I'm logged in as Admin. i.e. Admin's original PrgCtx has become the temporary one, which is then destroyed.Is this a bug, or should I expect the Admin session to take up the temporary session?

Find more posts tagged with

Comments

Donna Nalls

Hi John,I assume that your createAdminPrgCtx() method makes a call to $LLIApi.PrgSession.CreateNewNamed() method.I have noticed that if i am currently logged in as Admin user, CreateNewNamed will return the same session object that i am currently using.So, before you make a call to destroyAdminPrgCtx() method, you should make sure that your current prgCtx object is not the same as the object handed back from CreateNewNamed....i.e. if you have prgCtx variable as your session object...try something like:if (prgCtx != AdminPrgCtx) destroyAdminPrgCtx(AdminPrgCtx)endRegards,Donna

John Underhill

Interesting. On mine I return a new Admin session - so $PrgSessions has two entries - both for Admin user.Essentially I'm doing this:function createAdminPrgCtx()Object prgCtx = UndefinedString cnctName = $Kernel.SystemPreferences.GetPrefGeneral ( 'DftConnection' )Assoc prgAssoc = $LLIAPI.PrgSession.CreateNewNamed ( cnctName, { "Admin", Undefined } )prgCtx = prgAssoc.pSessionreturn prgCtxend

Donna Nalls

Hi John,I justed tested on LL 9.7.1 in an LL Request Handler and, as expected, CreateNewNamed handed me back the same object handle when i am logged in as Admin.I do see that there are some Callbacks that get checked in CreateNewNamed - i wonder if there is something there manipulating the object after it is returned from CreateNew()....A couple of thoughts:1) Step through the code when you call CreateNewNamed and see what is going on2) what LL version are you on and what type of object is your code in3) if all else fails, put a check at the beginning of your code to see if the current user is admin...if so, then assign AdminPrgCtx = prgCtx -- no need to call createAdminPrgCtx() -- then, you don't have delete the object.final thought: if you read the developer notes in $LLIAPI.PrgSession.CreateNew(), you will see that the intention is to return the same session object if the user record is the same as currently used.....so, i would say that something is changing that at some point in your environment.Regards,Donna

John Underhill

... after single stepping until my eyes fell out ...I was misleading myself as after I called to get an Admin context I had 2 Admin contexts. I assumed the second was new, but as you pointed out, it doesn't create a new one if you are already Admin. The second one was my user context and I was deleting it. I think I simply have to not delete the context if it is the current user!Thanks for pointing me the right way!Out of interest, the reason there were 2 Admin sessions seems to be that something creates a PrgCtx on Livelink startup - and doesn't clear it away. After just starting Builder there was an Admin context in $PrgSessions. It looks like it might be CASEBASIC.GetCaseTypes, but I don't have the time or will to dig further. Setting a tempAdminPrgCtx=Undefined or letting it go out of scope doesn't clear up the session objects hanging off of $PrgSessions.

Paul_Radu

I'm curious whether creating a temporary security context this way affects other existing ones, including in other threads. I hooked into a number of system events using LLIAPI NodeCallbacks and am having an issue with CBModePre when moving a document from one folder to another. Inside my callback I'm creating a temporary Admin context to perform some database queries and then releasing it again, which appears to undefine the fStatus feature of the dapiCtx in the LLIAPI NodeMove function (its value is ? after my callback returns). This in turn makes the LLIAPI CBNodeMove function throw the error "An unknown feature was specified" at the following line:

    rtnval = llParent.GetChildMoveOptions(dapiCtx, parentRec, nodeRec, dapiStatus.MoveInfo)

I'm including the relevant extracts from my code below. Can't seem to make heads or tails of what's going on.

Thanks,

Uwe

Tennessee Valley Authority

// my callbackfunction Assoc CBMovePre(DAPINODE node, Dynamic moveInfo = UNDEFINED, Dynamic context = UNDEFINED)  Assoc rtnVal  String errMsg  Dynamic apiError

  Integer status = DAPI.OK  Boolean ok = TRUE  if IsUndefined( rtnVal.OK )     rtnVal.OK = ok    rtnVal.ErrMsg = errMsg    rtnVal.ApiError = apiError    rtnVal.Status = status   end  // execute business rules  Assoc args  args.node = node  args.moveInfo = Assoc.Copy(moveInfo)  args.context = Assoc.Copy(context)  $TVABUSINESSRULES.Engine.ProcessEvent("MovePre", args, rtnVal)  return rtnValend

function void ProcessEvent(String eventName, Assoc args, Assoc retVal)  Assoc event  event.name = eventName  event.id = $TVABUSINESSRULES.Utils.GenerateUniqueID()  event.state = Assoc.CreateAssoc()  event.args = args  event.adminPrgCtx = $TVABUSINESSRULES.Utils.ImpersonateUser("Admin")  // rest of code removed because even if returning right here after creating the impersonation  // context the node move will fail; if commenting out the line above it will succeedendfunction Dynamic ImpersonateUser(String name = "Admin", String password = Undefined, String domain = Undefined)  String cnctName = $Kernel.SystemPreferences.GetPrefGeneral("DftConnection")  Assoc prgAssoc = $LLIApi.PrgSession.CreateNewNamed(cnctName, {name, password, domain})  if prgAssoc.ok    return prgAssoc.pSession  end  return Undefinedend

David Templeton

Uwe,

In the callbacks you need to get the user context from the node itself. Using code like this:

checkVal = $LLIApi.NodeUtil.FindDapiCtx( node )

if ( !checkVal.ok )

ok = FALSE

errMsg = checkVal.errMsg

apiError = checkVal.apiError

else

dapiCtx = checkVal.DapiCtx

prgCtx = dapiCtx.fPrgCtx

If you have the node object then you have the correct user context as well ( at least it should be ). But you should be using that

Simply creating a program context will have unpredictable side behaviours such as:

<![if !supportLists]>- <![endif]>Auditing of events using this created session will be incorrect

<![if !supportLists]>- <![endif]>The new context can bump another context off the cache and in some cases could be the one currently in use if the cache is small enough and multiple ‘local’ sessions are created.

As for effect on the other threads, no, each thread is isolated in these contexts. The dapistatus would be the correct reference is the method above is used.

Regards

David Templeton

OpenText

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Thursday, December 27, 2012 5:09 PM
To: eLink Recipient
Subject: Related question

Related question

Posted byuwradu@tva.gov (Radu, Paul) On 12-27-2012 17:07

    rtnval = llParent.GetChildMoveOptions(dapiCtx, parentRec, nodeRec, dapiStatus.MoveInfo)

I'm including the relevant extracts from my code below. Can't seem to make heads or tails of what's going on.

Thanks,

Uwe

Tennessee Valley Authority

// my callback

function Assoc CBMovePre(DAPINODE node, Dynamic moveInfo = UNDEFINED, Dynamic context = UNDEFINED)

  Assoc rtnVal

  String errMsg

  Dynamic apiError

  Integer status = DAPI.OK

  Boolean ok = TRUE

  if IsUndefined( rtnVal.OK )

    rtnVal.OK = ok

    rtnVal.ErrMsg = errMsg

    rtnVal.ApiError = apiError

    rtnVal.Status = status

end

  // execute business rules

  Assoc args

  args.node = node

  args.moveInfo = Assoc.Copy(moveInfo)

  args.context = Assoc.Copy(context)

  $TVABUSINESSRULES.Engine.ProcessEvent("MovePre", args, rtnVal)

  return rtnVal

end

function void ProcessEvent(String eventName, Assoc args, Assoc retVal)

  Assoc event

  event.name = eventName

  event.id = $TVABUSINESSRULES.Utils.GenerateUniqueID()

  event.state = Assoc.CreateAssoc()

  event.args = args

  event.adminPrgCtx = $TVABUSINESSRULES.Utils.ImpersonateUser("Admin")

  // rest of code removed because even if returning right here after creating the impersonation

  // context the node move will fail; if commenting out the line above it will succeed

end

function Dynamic ImpersonateUser(String name = "Admin", String password = Undefined, String domain = Undefined)

  String cnctName = $Kernel.SystemPreferences.GetPrefGeneral("DftConnection")

  Assoc prgAssoc = $LLIApi.PrgSession.CreateNewNamed(cnctName, {name, password, domain})

  if prgAssoc.ok

    return prgAssoc.pSession

end

  return Undefined

end

[To post a comment, use the normal reply function]
Topic:	Using a temporary Admin PrgCtx - and destroying it
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Paul_Radu

David,

Thanks for your quick response. The problem is that some of the operations I perform need elevated permissions that most users don't have. In the sample code I posted it's happening using the Admin ID but in production it would be a service account with Admin privileges. So there really is no way around obtaining an elevated security context. The code for the ImpersonateUser() function I obtained right here in this forum and was in fact suggested by one of the OT support folks, so I would assume it's a supported way of doing things.

Uwe W. Radu

TVA

Ian_MacLachlan

Is it possible to save the current/original context in a variable first, then invoke your ImpersonateUser() and after your processing restore the original context?________________________________________From: eLink Entry: Content Server Development Forum [development@elinkkc.opentext.com]Sent: Friday, December 28, 2012 8:35 AMTo: eLink RecipientSubject: RE Related questionRE Related question Posted by uwradu@tva.gov (Radu, Paul) On 12-28-2012 09:32David,Thanks for your quick response. The problem is that some of the operations I perform need elevated permissions that most users don't have. In the sample code I posted it's happening using the Admin ID but in production it would be a service account with Admin privileges. So there really is no way around obtaining an elevated security context. The code for the ImpersonateUser() function I obtained right here in this forum and was in fact suggested by one of the OT support folks, so I would assume it's a supported way of doing things.Uwe W. RaduTVA________________________________[To post a comment, use the normal reply function]Topic: Using a temporary Admin PrgCtx - and destroying itForum: Content Server Development ForumContent Server: Knowledge Center