Parameterised Secret and made the number of stars used not the same length as the underlying value #4
Conversation
…ength as the underlying value
|
@Michaelt293 Awesome one 👍 |
|
@Michaelt293 Would u mind resolving the conflicts? Sorry that I kept pushing things after that.. That is mainly on automatic Safe instances using another set of macros |
|
Sure, I don't mind resolving merge conflicts. Now I have thought about it a bit longer, I am not sure whether we should have |
|
Absolutely. I did think about it and we can have a constant. And absolutely, it should be parameterised. My password can be anything and not just string. !! Good point.
However, the safestring.scala macros has no idea about secrets or password. Nor the macros in safe.scala (for automatically creating instances of safe for case classes) has no idea about secrets or password. It’s a separate concern. I will explain why the separation of concern. .
The safe instance is more of a “toString” behavior.the macros in safestring.scala uses safe to show the field names and values but it doesn’t worry about secrets or passwords.
Macros in safestring.scala verify if you passed a string or case class at compile time (if not it doesn’t compile and tells the user you are doing something wrong), and if it passes this constraint, it then pretty prints your case class (remember this is something people always tried to solve using shapeless which affects compile time ) or simple string typesafely. In other words, the safestring.scala macros delegates the job of pretty printing typesafely to safe.scala ( https://afsalthaj.github.io/safe-string-interpolation/pretty_print.html)
An important point is Secret is a case class which user may or may not be interested in. He may use a type on his own and choose to not depend on a new data type. If he can label his secrets in some other way, we should be able to support that as well. That bridge is taken care by safe typeclass.
For instance , l as a user may choose to in fact expose a part of password or a hash of it and I may choose to use a tagged type for my secret. And I don’t want to wrap it further with Secret. It’s already wrapped and since it is tagged type I can anyways define a behavior (behavior of toString) without labelling it further with secret (https://afsalthaj.github.io/safe-string-interpolation/secrets.html)
…Sent from my iPhone
On 27-Dec-2018, at 9:18 AM, Michael Thomas ***@***.***> wrote:
Sure, I don't mind resolving mode conflicts.
Now I have thought about it a bit longer, I am not sure whether we should have hiddenLength as a method on the Safe type class. Perhaps it would be easier just to hide the value with a masking string of a constant ~six stars. That might make the macro you have easier to implement and I'm not sure how much value we get from the length of the hidden value (masking string) being dependent on the type. Also, I strongly believe that we should parameterise Secret so that we can hide types other than string (as done in this PR). If we make the masking string a constant six stars, we no longer need a Safe type class constraint on the Safe type class instance for Secret and will be able to hide any type.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Also very keen to get your PR (the parameterisation of secret and implementation of your suggestion of removal of length of password) resolved with conflicts. |
|
I've resolved the merge conflict now. I think there might be an issue with the SBT build since I was getting a build error when I tried running the test. |
|
Also, I can rebase my branch if you want tidy commits. |
|
@Michaelt293 I would like you to push this PR again with the suggestions mentioned.The PR is closed automatically as I did a commit history cleaning. Sorry for the incovenience but I had to do this to get rid of the weird commit history in master branch and I had to clean it before the project gets more audience, otherwise it can be problematic in future. |
No description provided.