Print Page | Close Window

Principal object on the Server

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=1266
Printed Date: 23-Apr-2025 at 9:07pm


Topic: Principal object on the Server
Posted By: orcities
Subject: Principal object on the Server
Date Posted: 19-May-2009 at 3:01pm
Today I started having a problem with my BOS I am hoping to get some help.
 
After alot of digging I have come up with the following conclusion.
 
Any entity that inherits from my AuditableEntity class performs security checks using the SaveSecurityCheck override. At that time I check to see if the current Principal objects has suffecient rights, which they do. Then I call the base classes AuditSelf method which then goes on to call another method to create the AuditValues. At that point I perform another security check to see if this person can create new records. If they can then it bypasses this and moves on. If not it marks this item as InActive and then it is flagged to be viewed and approved by an Administrator or any other person with permissions.
 
The problem I am having is that when I go to create the AuditValues the Principal object fails for the same security check it passed on before it entered the AuditSelf method.
 
What can be causing this? I can not recreate this on the development version. I found that this is only happening on the version running through the BOS.
 
 
 


Replies:
Posted By: GregD
Date Posted: 21-May-2009 at 12:00pm
I confess to having a bit of difficulty following the thread there, but it seems odd that you are performing what you describe as "the same security check" twice.  If, as you have your security structured, the right to save records is indeed the same as the right to create them, then there ought to be a way to structure the code so that the check is only performed once.

I realize this sidesteps your question, but I ask in case it might be possible to make the code simpler (with all the benefits of that) and solve the presenting problem in one stroke.

Posted By: orcities
Date Posted: 21-May-2009 at 12:52pm
The audit is performed on the save which fires the SaveSecurityCheck. Then if the person does not have the appropriate priveledges it changes a value and then resaves the info then firing the SaveSecurityCheck again.
 
 

Posted By: orcities
Date Posted: 21-May-2009 at 1:08pm
Let me explain further. This is based off of Wards CABANA AuditableEntity class. Only a few changes.
 
AuditableEntity.SaveSecurityCheck(...)
check rights if ok move on
AuditSelf(pPrincipal)
 
Principal exists at this point
AuditSelf(...)
Starts Createing audit values
calls a class (AuditValue) to determine if Add/Edit/Delete and if it is add it checks Principal object again. At this point the Principal object fails.
 
This only happens on the BOS version not the local version.
 
 

Posted By: kimj
Date Posted: 27-May-2009 at 8:25am
Are you passing a principal into AuditValue or are you grabbing the Thread.CurrentPrincipal?  Are you starting up a new thread anywhere in this process?  How is the AuditValue class instantiated?  Is there a static reference to it?  Is it possible that AuditValue was instantiated on another thread?
 
The BOS is multi-threaded, with each request processed on a separate thread.  The BOS sets the Thread.CurrentPrincipal on each request thread to the principal representing the calling user, and this should be available throughout the lifetime of the thread.  Any other threads started by application code will not have the same CurrentPrincipal unless specifically set.
 
 

Posted By: orcities
Date Posted: 27-May-2009 at 10:07am
I am calling the Current Principal object and not passing it in. I am creating the audit values by calling the static AuditValue.CreateAudits which then goes to the appropriate static class AuditNewEntity where it calls the current principal.
 
I am not knowing creating my own thread.
 
 
 

Posted By: kimj
Date Posted: 27-May-2009 at 11:23am
My guess is that a fetch is actually occurring at some point during this processing and causing the Thread.CurrentPrincipal to be reset.  A guess, but the debuglog might show something.
 
Since AuditArgs is created with an IPrincipal, which you know to be good at that point, you could try modifying the AuditArgs class to keep and expose the IPrincipal, and then check that in subsequent processing in AuditNewEntity, et al.

Posted By: orcities
Date Posted: 27-May-2009 at 12:45pm
I already had passed the principal to the AuditArgs for the Audit value but was not using that principal. My assumption was they were all the same principal object.
 
Thank you for your help.


Print Page | Close Window