Question: Custom mapping interceptor

[kersane]

Hi, is there any way to intercept mapping while setting field/property value with some user provided context? In our case, we need to do some masking to several properties given some current user policy doing the query. Currently, we loop through materialized data, and re-set maksed property.

[mgravell]

Can you perhaps give a more concrete example of what you're looking for? I suspect the answer is "not really", but if there's merit in the need, we might be able to sort something.

[kersane]

Similar issues/screnario i've found #360 #503

As for #503, how can we inject key information for encrypt/decrypt operation? since dapper control the instantiation of the class.
#360 Opening up ITypeMap/IMemberMap or any other mechanism to allow api user to control value translation might be a good option

[mgravell]

I wonder if the solution here - in the future, not fully usable right now - would be to use the DapperAOT TypeHandler<....> API. We could tweak this to allow it to be specified on individual members (fields/properties), so that you can enable it on some columns and not others, via attributes. Thoughts? Note this won't work "today" - it needs more work.

As for passing keys: I would assume AsyncLocal<T> would be the most viable approach here. We don't have a context arguing to play with, unless we pass in the raw object args, and that is often a compiler-generated type, so not very helpful to you.

[kersane]

I haven't look through Dapper AOT, will check it later. My assumption, by controlling via attributes, api user still need some context to pass around, to check whether current app user has the right policy to access the data, here is the background we would like to achieve

In our case, app users are given so called access policy, that govern what data fields a user are allowed to see, either by filtering or masking. On filtering, we match the view model against the policy and build the conditional 'where' query, can be implemented naively, no need to touch internal Dapper. On masking, currently we loop through QueryAsync result, and do the same matching rule, and replace the value (this is where some custom whatever it might be called, will play nicely)

AsyncLocal<T> might be a good option here, though it might clutter simple view model, will try to play with it for now.

Please point out some area that i need to look, i'll try to help if i could.

[mgravell]

Async local is probably the most appropriate solution for ambient state, in the absence of a dedicated state API/parameter (separate to args); ok terms of usage: just set it once the context of your request/whatever - typically right at the start after authenticating, and: that's it

[kersane]

well received, thanks @mgravell, closing for now.