Question

Version 9.0 Redacting information in Error Log

Forum|Forum|11 months ago
June 19, 2025
5 replies
2 views

Dear Community Members,

Has anyone experienced information in the log being redacted. I found this in the latest documenation.

However, i see no pattern of what is considered sensitive.

I have a data table dump in the decimal positions are redacted.

I am logging the keys and values of two dictionaries. in both dictionaries the value is an integer. One value is shown while the other value in redacted. Both values come from a text member of a dimension member.
In other cases i am logging the name of the business rule and the name of the function. Sometimes the RULENAME is redacted, sometimes it is not. Which leads me to believe that the logic thinks that the name is sensitive?!

Is this sensitivity controllable maybe on the app settings on the server? Cause it seems overly sensitive or plainly wrong in determining what is sensitive and what is no.

R

rhankey

It will be interesting to hear if there is a config parameter by AppServer, App, or User somewhere to turn this "feature" on/off, or if there is way to toggle it on/off when logging specific output.

In the meantime, the workaround I have been using to overcome this new "feature" is by formatting numeric values as I'm writing them to the log. Eg:

api.LogMessage("DecValue="+DecValue.ToString("N2")+", IntValue="+IntValue.ToString("0"))

W

WernerNAuthor

It is a bit frustrating that all of us have to come up with work around solutions that actually increase the debugging effort for a 'solution' that should not even be there in the first place.

R

RobbSalzmann

It may help to know that OneStream is actively tightening security of its platform to meet the very stringent requirements of FedRAMP certification. While the log redaction situation creates a little extra work for developers, there are a couple of things that I think offset this:

FedRAMP means OneStream can be sold into the massive government municipal market - opening up opportunities, big projects for many of us.
V9.1 introduces the Business Rules Profiler. Using this tool will negate the need for a majority of the BRApi.ErrorLog.LogMessage calls currently used for debugging.

Jack's workaround above is brilliant in it's simplicity and can be implemented with a simple find and replace.

W

WernerNAuthor

Thank you rhankey
i thought about converting to string. did not think about the N2.
However, the strange behaviour observable is that, and again without a pattern, i also get strings redacted. I write the rule and function names to the log and sometimes the rulename, sometimes the function name is redacted (I have both in a constant).
And gain, thanks for the tip and responding so fast. let;s see what our OneStream friends are saying.

J

JackLacava

I hear you, I agree that we went a bit overboard with this feature. It gets triggered in "interesting" cases, like when a string has 8 consecutive zeros... It can be maddening.

Future releases will likely dial it down a bit.

W

WernerNAuthor

Thanks Jack,
The new feature redacts this name of a business rule "WsasDataManagementStep", or this name of a function "LoadMarketLookUpDictionary". English is not my first language, but I cannot find anything wrong with these names and i built 'Clean up words' algorithms before.

But anyway, I would hope that we get a hotfix quickly as the current feature pretty much renders logging useless. And I have to admit that i find it difficult to believe that one would log anything that is sensitive when i can right click on any cubeview that might show sensitive financial information and export to Excel. Or is Version 9.0 also redacting when exporting to Excel.

On a side note Jack, great presentation on Dynamic Cubes on Wednesday.

W

WernerNAuthor

To add some information so that OS Development can maybe put an option into App Settings to turn this off:

Trying to evaluate if i am connected from target app to source app.
1) In the error log trying to show the session ID (even though i dont really need it but just displaying the whole thing):
Check session state User: xxxx, TimeAuthenticated: 20250623195015, AuthSessionID: [REDACTED], Application: XX_YYYYYYY_9.0
2) In the message box of a my dashboard extender
Check session state User: xxxx, TimeAuthenticated: 20250623195015, AuthSessionID: d23c1186e28041e2af226a0be74b3ec7,

So, at least in a dashboard extender rule I can now convert all my logging to a message box. In other rules i am a bit stuck.

R

rhankey

Outputting to the file share also sidesteps the [redacted] messages.

But agreed, we need a way to turn-off this "feature" (not just dial it back), as it makes debugging logic much more difficult.

It would seem a far better way to handle the redacting would be to write unredacted message to the ErrorLog, and only apply the redacting the entire message (not just amounts containing a certain number of zeros) when displaying the log if the user looking at the log is not the owner of the log entry or is not a member of an authorized group.

W

WernerNAuthor

Awesome, thanks rhankey
Outputting to FileShare is an even better solution. i will use that immediately.

R

RobbSalzmann

Use of a standard logging framework would make most of this less brittle through extension. A working debugger would help make much of this moot. Ability to debug running business rule logic would put OS lightyears ahead of the CPM field from a development perspective.

Ultimately, logging should be the responsibility of the developer. If that developer is OneStream, then start there. Use a standard logging framework and establish logging practices.

Redaction where logging is our only form of debugging, may potentially cripple the development process.

I also think that OS will find that redaction is a brittle, reactive design approach - on they will be in constant maintenance of. Extend a standard framework with redaction services and make that configurable.

An alternative to redaction is to extend a logging framework with something specifies something written to the log as "Administrative" such that it doesn't get listed in the log viewer unless the user is in the Administrator group.

Logging doesn't sell the product. Use off the shelf standard frameworks, and focus on features that sell.

W

WernerNAuthor

Couldn't agree more, Robb! Alas, no word yet that the 'feature' of redacting is going to be removed, made optional, or made at least somewhat controllable.
Besides the fact that it limits our ability to test, it also just seems arbitrary. I mentioned it before, but someone really needs to explain to me what purpose redacting of the decimal positions serves. And one, albeit repeated example, the redacting of the value of a constant called CLASSNAME, but not redacting it when I change the name to RULENAME.

All of this is secondary to your much more important point that Onestream needs a debugging/logging framework.

And while i am on it, may I add a feature to check out and check in rules, and actually every object, so that we don't overwrite each other's work. I can check out and check in a report in narrative reporting but not a rule.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded