This article is about proposed internal refactorings in NetServer. If you have onsite code that includes NetServer in-process and uses or contains code that refers to ISoDataLookup or BeginIgnoreSentry, then this is for you. If not (for instance because you only work with our Agent API or Online), then read out of interest, or spend your time elsewhere.
The several ways to Ignore Sentry
Sentry is the data access control mechanism in NetServer, and it is deeply connected to our database layer. Access control is not something application developers need to remember; it’s something that is always there.
But sometimes there is code that acts on behalf of the system, not the particular user. For instance, when a Dynamic Selection is completely enumerated (all members fetched), we write that member count to the selection row; it’s a useful thing to track. And this should be done even if the user only has read access to the selection. For just that operation, we want to turn off the access control; this is what IgnoreSentry means.
In other cases there is a whole block of code, multiple database accesses, that needs to turn off the access control. And, not least, when the Sentry code itself needs to look at a database field value to do its access control calculations, it needs to not trigger itself recursively.
Each of these IgnoreSentry scenarios has its own mechanism. They have evolved over time and (among other things) are not compatible with async/await. They also consume more CPU cycles than we’d like.
The big refactoring
TL;DR: We are going to combine instance-dependent IgnoreSentry (implemented through ISentryIgnorable), data lookup IgnoreSentry (implemented through ISoDataLookup) and code-block IgnoreSentry (implemented through ThreadManager static methods) into one common system.
The exact details are not 100% clear yet – it’s complex, critical, hot-path code and we will need to evolve the refactoring iteratively before we know the answer. We will attempt to minimize breakage, but there is probably going to be some impact.
Timeline and feedback
These changes will be released either in 10.x, or in 11. For us it would be most convenient to include them in some 10.x version, as and when the coding is done. But it depends on the impact on the community.
Note, however, that such impact should be limited to partner code that actively uses these mechanisms. We believe that there is little-to-none such code out there… and this is your chance to enlighten us. Does this sound familiar? Have you written sentry-related code, IgnoreSentry, anything related? Do tell!
All Replies (2)
We do use the 'code-block IgnoreSentry (implemented through ThreadManager static methods)' a few times to make changes on behaf of a associate (impersonation) that they normally can't do through the GUI. (by design). and to make sure we do not end up in a recursive loop when doing certain operations (if this is actually necessary I don't know, all developed before my time ;))
Due to impersonation not being available on the Agents API level, we never refactored this program to not use NetServer Core. (which we would like to switch off from)