Self-obfuscating value objects in PHP

37 points by eamann 3 years ago | 8 comments
  • biryani_chicken 3 years ago
    Sounds like it would be a good idea to get the CI process to check for usage of debugging functions. I'm sure it would be possible to write a phpstan rule to forbid var_dump. Maybe another solution would be to make them noops on production.
  • progre 3 years ago
    Slightly off topic, but when I was debugging a release pipeline in Azure Devops I discovered that they do a surprisingly good job of keeping secret values out of the logs: I was trying to dump a connection string with inline powershell but found that it was always masked with **. I had to resort to base64 encode the connection string to get it to print. I suppose they scan the output buffer and compare it with known secrets before printing.
    • egeozcan 3 years ago
      Ah, stuff like this always reminds me the famous (or rather infamous?) hunter2 (or rather *******?) conversation:

      http://bash.org/?244321

    • pdenton 3 years ago
      From TFA:

          > an interface, which cannot implement or inherit from other interfaces
      
      An interface in PHP most definitely can extend multiple other interfaces.
      • heythere22 3 years ago
        > This subtle nuance (value equivalency versus object equivalency) can cause problems, particularly if variables are passed by reference to any other functions in your codebase.

        Value objects may be great for leveraging the type system to help you write better code by e.g. having only one place for validation. But why should you pass scalar variables by reference? That makes it really hard to reason about what functions and methods do.

        • withinboredom 3 years ago
          There’s an RFC in discussion to add a Sensitive Value attribute that would prevent values from being output in the logs. It won’t stop serialization of the values though.