-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More masking options! #5
Comments
Currently masking logic is customized via two parameters: I would like to simplify it. I want to get rid of the Moreover, I'd like to change the parameters send to that masker object. At the moment we're sending a hash of options, but I want to send an attribute value as the first argument. This way we a very simple procs like |
I agree with @skalee on the usage simplification, this still allows the usage of custom masking objects in the simplest form a Proc 👍 |
Also guys, do we support marshalling as in the original gem? This is totally okay to me, but I suppose this feature is useful than other ones. Perhaps it's better to remove it rather than supporting it. What do you think? |
I think we should still support marshaling but maybe in a Rails-native way? Or as long as there is a way to support masking marshaled data without needing marshall support within the gem, it is good enough. |
I wonder what the cc: @ronaldtse @abunashir |
@skalee I suspect it was used to support attributes that uses different column names like |
The discussion on the |
The "Proc as parameter" has been fixed with #23. |
So I wonder what new built-in maskers can be introduced.
->(value:) { "email+#{value.gsub("@", "_at_")}@example.com" }
What else could we mask in a way which is common enough so that a built-in masker is advocated? What do you mean by scrambling algorithms, precisely? I guess replacing sensitive values with some legit-looking random ones is a better idea. cc @ronaldtse |
I think we could bridge the classes of the fake data gems (faker / well_read_faker / ffaker) so you can just do: attr_masker :email, masker: :email, unique: true
attr_masker :last_name, masker: AttrMasker::Maskers::Name
attr_masker :telephone, masker: :tel
attr_masker :html_content, masker: AttrMasker::Maskers::HtmlIliad |
Right now you can do: attr_masker :email, masker: proc { "#{SecureRandom.hex(10)}@example.com" }
attr_masker :last_name, masker: proc { FFaker::Name.last_name }
attr_masker :telephone, masker: proc { FFaker::PhoneNumber.short_phone_number }
attr_masker :html_content, masker: proc { FFaker::HTMLIpsum.fancy_string } IMHO bridging faker etc. is nothing but a maintenance burden. I mean implementing built-in maskers make sense only when masked values are derived from the original ones, or random value generator isn't that trivial. |
That's true @skalee . Less burden is always better! 👍 |
Regarding:
The motivation is to use the huge repository of the different combinations of HTML structures already available to us, so by just applying masks, our tests could already have a rich stash of test HTML to work on. This is useful for testing out stylesheets and wysiwyg editors, for instance. But I believe this is not essential, as it can easily be written by the gem user in the Proc. |
It seems we'd also need something like the following: attr_masker :stuff, masker: ->(model:) { model.species =~ /cat/ ? 'miao' : 'woof' } i.e. the ability for the |
Agree with @ribose-jeffreylau . @skalee would you have time to implement this? |
@ronaldtse @skalee Actually I'm already working on it right now :) |
Proc
as parameterThe text was updated successfully, but these errors were encountered: