Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Sep 27, 2018 @ 13:08
    Peter Duncanson

    Could we have "sensitive data" flags for doctype properties?

    As of 7.9 and thanks to GDPR we now have the notion of "Sensitive Data" for member fields (

    I would like this rolled out to properties on Doctypes.

    I'm not sure on how this was achieved for members but wondered if the same code could be rolled out to more areas of Umbraco? I'll be having a poke around in the commits to try to get my head about what this might involve.

    My driver for this is our GraphQL work, we ideally want to make all the properties public but hide the sensitive ones (you wouldn't for instance want the cost price for an Amazing Japanese Kitchen Knife being available via your public API. If we could flag those fields as sensitive then GraphQL would know automagically not to make them public by default.

    It would add another level of protection from fields leaking out where you might not want them.

    Anyone got any thoughts on the viability of this one?

  • Matt Brailsford 2403 posts 11654 karma points MVP 6x c-trib
    Sep 27, 2018 @ 13:20
    Matt Brailsford

    Interesting scenario, and I'm sure it would be possible.

    I can't help thinking though that it feels to me to be a different use case and at this level, it's more about granular permissions for you API, than it really is about "sensitive data" from a GDPR perspective. I'm not saying it's a bad idea, I'm just wondering if it's the right solution for the issue you face?

  • Anders Bjerner 422 posts 2333 karma points MVP 3x admin c-trib
    Sep 27, 2018 @ 13:20
    Anders Bjerner

    I was a bit confused as first when this was only added for members, but not for content and media types.

    I haven't had a need for it yet though, but I think it makes sense to add support for content and media types as well.

  • Lee Kelleher 3890 posts 14696 karma points MVP 9x admin c-trib
    Sep 27, 2018 @ 14:11
    Lee Kelleher

    Same thoughts, as in why wasn't it available for content/media - and yup, I haven't needed it either.

    BUT I like the idea, Pete!

    I agree with what Matt said about the intent of such feature. I'm thinking a more generic "property wrapper" approach (with checkbox, or whatever) could be something?

    In terms of packages, I've seen this done recently on this package: Nullable Types: ... although it's not wrapping existing properties.

    Good ideas!

    - Lee

  • Lee Kelleher 3890 posts 14696 karma points MVP 9x admin c-trib
    Sep 27, 2018 @ 14:19
    Lee Kelleher

    Obligatory cross-linking to your Property Decorators thread...

    ...which I meant to respond to at the time, (but didn't, curses time!)

  • Alan Mac Kenna 145 posts 382 karma points c-trib
    Sep 27, 2018 @ 14:17
    Alan Mac Kenna

    Not sure the example quite falls into the GDPR zone but totally see it being useful. Sounds more like a private property flag than a sensitive data (ala GDPR definition) property flag.

    If data is sensitive, it would ideally be encrypted when stored at rest and only visible to users whose roles allow it in the backoffice. A private data flag at least for the way you intend it Pete, might need to be treated differently.

  • Sebastiaan Janssen 4876 posts 14511 karma points MVP admin hq
    Sep 27, 2018 @ 14:55
    Sebastiaan Janssen

    This is not the "you're doing it wrong" post.. or is it?

    I find the example a little bit worrying: you're storing data that is not to be public in something that's eventually called PublishedContent.

    This always worries me, there's only a small little thing that needs to happen to make this go wrong:

    • An editor puts the price in the wrong field
    • A developer puts the wrong field in a template
    • A developer didn't realize their RSS feed would include the private info
    • They didn't realize their GraphQL API would contain this info
    • They forgot to mark this private field as private and it leaked anyway

    I know there's a million reasons of where you'd want to put this info in there but all levels of misdirection are (as usual) only as strong as the weakest link (in this case, the human factor).

    Background: "sensitive data" was always meant as some help to prevent users with Umbraco access to view certain data (yes, also vulnerable to the "human factor") or export certain data.

    It was never meant for this type of usage and I doubt if it would be great to use it as a way to prevent data that you're publishing from being published.

    To take this even further, you're bound to confuse the editors as well: "when I click the Save and Publish button, I make everything I just typed public... except that special property "X" 🤔".

    Don't get me wrong, I'm all for good hacks, but this is a difficult one for me.

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Sep 28, 2018 @ 11:01
    Peter Duncanson

    Some excellent response on here folks, thanks for chipping in.

    Just to be clear this isn't a GDPR thing more a "how can we leverage whats already there" thing (if we can at all).

    More I ponder it the more I think a separate solution is the right way to go. This is a good thing but also causes me some headaches. We've built a rough and ready UI in a dash board to manage which fields should be public for our GraphQL work. Its enough to prove the point and get someone up and running real fast.

    The more I think about it and work on it the more I think that this could be useful for any API really so I'm pondering pulling this out into its own package ("API Permissions for Umbraco") or something like that. This is again meta data about data, a common theme it seems.

    So if the price example is to flakey for you then how about this one. In one of our client sites we have about 150 fields that you can use for a doctype (A hotel in this case). Some of which make little sense being exposed on the website or to a 3rd party who might be consuming our endpoint. Why clutter up the schema with a tonne of fields that will never get used (although they have internal meaning to us which is why they are there). So you could hide those fields from the schema of your API and make it nice and lean and to the point. That's the sort of thing we are aiming for, a quick UI that lets you choose which fields you want to expose.

    So far we've got the idea of Accounts (think of these are users of the API) which in turn can have Account Settings (which fields can each account see and what can they do with it). You can have different permissions on a field (read or write or none). For now we are just rolling out with a Default user that you have to opt into which fields they can see, out of the box for now they won't see anything you have to use checkboxes via our UI to enable fields. The ground work is there and in to allow us to have different users with different permission (so you could update data for instance if you had the access rights and pass in a token).

    My thinking with trying to leverage what was already there was to see if we could quickly make some informed choices about which fields we could whitelist automatically to save you having to click hundreds of checkboxes. We could do a bit of this already but allowing you to make Compositions public or certain common fields (bodyText, nodeName, id, etc.) out of the box. For now though we will go the simple root of you have to opt in for everything.

    Some great discussions this week. One of the things I loved about retreat was chats like this, the best ideas come from a seeding of an idea and then having multiple people chime in with their experience and thoughts. For that I thank you :)

Please Sign in or register to post replies

Write your reply to: