Forum Discussion

WernerN's avatar
WernerN
Contributor II
2 months ago

Version 9.0 Redacting information in Error Log

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.

Parsing
System

16 Replies

  • RobbSalzmann's avatar
    RobbSalzmann
    Valued Contributor II
    23 days ago

    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.

    • rhankey's avatar
      rhankey
      Contributor III
      23 days ago

      (edit) - As I thought this through a little further.

      While I would love to have access to a runtime debugger for business rules, a runtime debugger does not replace the sort of degugging info I need to write to a log.  A runtime code debugger and a logger serve two different needs.

      For logging, I personally think a far simpler and better solution would be to provide a pair of new api/BRApi.UserLog() functions  The idea of a user log would be to provide us a place to write whatever debugging type info we need without any redacting.  The user log would only be viewable by the user who invoked the logic, and auto-delete when the user logs out the last session they may have open.  As such, the user log might persist for a day at most.  If you need to be debugging logic that someone else needs to run, then use the existing ErrorLog that can have some reasonable redacting (by "reasonable", I mean far less redacted than is currently being done with 9.0).  A UserLog needs to collect log info for the one or more sessions a user may have running at any given time, so it is possible to view the UserLog from another session the user has open.  It might even be handy to have a button to access the user log placed next to the Task Activity button, so non-admins can easily access their user log without having access to System.

      The vast of majority of debugging stuff I personally write to the ErrorLog is of no value much more than 5 minutes later and simply makes it harder to find the log entries that do belong in the ErrorLog.  Some of my log entries will still need to go to the ErrorLog, but the vast majority would more rightfully belong in a UserLog.  An added benefit of a UserLog is that the entries will already be filtered to that user and with no other fluff.  The only downside of this possible UserLog solution would be if one forgot to turnoff debugging when done (not that we ever forget), it might take longer for us to notice, during which system performance would remain less than optimal.

      • RobbSalzmann's avatar
        RobbSalzmann
        Valued Contributor II
        23 days ago

        Please don't let OS off with this approach.  If you've ever used a debugger to troubleshoot code, you know the amount of time it saves vs having to physically type out BRApi.ErrorLog.LogMessage(si, $"Some Value is: {value}") to write every last variable to the log, then stop execution and read the log.

        The very idea that code you had to write to "debug", you have to delete 5 min later is the very reason for the debugger.  With that tool you never have to write the code that writes to the log in the first place.  Huge productivity increase immediately.  Run the code, follow execution flow, and observe the variable values in realtime, in the actual code.  You'll almost never use the log for this again.

        At a minimum, we should be using a live console and not the log for writing things that pertain to troubleshooting runtime execution.

    • WernerN's avatar
      WernerN
      Contributor II
      23 days ago

      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.

  • WernerN's avatar
    WernerN
    Contributor II
    2 months ago

    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.

    • rhankey's avatar
      rhankey
      Contributor III
      2 months ago

      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.

      • JackLacava's avatar
        JackLacava
        Community Manager
        2 months ago

        we need a way to turn-off this "feature"

        I am not the biggest fan of this feature, but there are legitimate concerns about outputting passwords, api keys, and the likes, so it likely won't be something you can just disable. It will become smarter very soon, though, so hopefully it won't be a real problem anymore.

  • JackLacava's avatar
    JackLacava
    Community Manager
    2 months ago

    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.

    • fchaves's avatar
      fchaves
      New Contributor
      2 months ago

      Hi Jack, 

      It would be nice if admins could choose if they want to apply this feature into their apps or not. 
      There are some use cases which require to see the values in the error log. And yes, there are some workarounds such as applying formatting and adapting your number, but still, you would need to start testing which formatting adaptations you need to make to your variable for each and every variable you need to see. 

      Thank you!

      • WernerN's avatar
        WernerN
        Contributor II
        2 months ago

        I could not agree more with fchaves​.  Debugging is difficult at best with this new 'feature'.  And I really dont see a reason for some redacting applied.  If i call a rule name variable CLASSNAME it is redacted, if i rename the variable to RULENAME it is not redacted. If i want to show a GUID part of the GUID is redacted.  On amounts in the log the feature redacts the decimals.

    • WernerN's avatar
      WernerN
      Contributor II
      2 months ago

      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.   


  • WernerN's avatar
    WernerN
    Contributor II
    2 months ago

    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.

  • rhankey's avatar
    rhankey
    Contributor III
    2 months ago

    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"))