Indicate record as being "protected" or not #356

New issue

Open

opened 2026-06-25 07:20:50 +00:00 by jsheunis · 3 comments

jsheunis commented

2026-06-25 07:20:50 +00:00

Owner

There's a feature of N3 (the main shacl-vue dependency for working with RDF) that one can use to specify that a quad belongs to a specific (sub)graph. A quad in an N3 dataset is actually created with:

quad(subject, predicate, object, graph)

When shacl-vue fetches data from all configured backend endpoints (in our deployment: public and protected), it receives triples and adds them to the N3 dataset. At this point we can add the graph id in order to identify the quad as coming from whichever backend collection it came from.

it would also allow, in principle, filtering records on "public" vs not.

It is to be figured out whether, when the record is serialized to be submitted to the backend in TTL format, we could/should tag the metadata with the id of the originating graph.

It could be useful to know, in the UI, whether a record comes from a "protected" or "public" place (think: showing some indicative icon on the record if it's from a backend that requires authentication; we've touched on this previously I think). There's a feature of N3 (the main `shacl-vue` dependency for working with RDF) that one can use to specify that a quad belongs to a specific (sub)graph. A quad in an N3 dataset is actually created with: ``` quad(subject, predicate, object, graph) ``` When shacl-vue fetches data from all configured backend endpoints (in our deployment: public and protected), it receives triples and adds them to the N3 dataset. At this point we can add the graph id in order to identify the quad as coming from whichever backend collection it came from. it would also allow, in principle, filtering records on "public" vs not. It is to be figured out whether, when the record is serialized to be submitted to the backend in TTL format, we could/should tag the metadata with the id of the originating graph.

jsheunis commented

2026-06-28 21:52:31 +00:00

Author

Owner

I worked on this a bit. It's actually much simpler to just extend the code in 0de30f1361 and add the source of a record to the specific item in recordItemsAll. The source can be determined from the fetch url and config. Our config for the service base url option looks like this:

service_base_url:
   - url: https://pool.v0.trr379.de/api/protected/
     type: write
   - url: https://pool.v0.trr379.de/api/public/
     type: read

So from the fetch url we can get the element in this array, and extract the associated type, and we take the (implicit) convention that write is protected and read is not. This is brittle, so we need a better way to map this in future...

So for data coming in from the backend we can log the source. And for data created or edited in the app we set the source to protected explicitly.

And then we can e.g. show a lock icon when an item has the protected source, like this:

I worked on this a bit. It's actually much simpler to just extend the code in https://hub.psychoinformatics.de/orinoco/shacl-vue/commit/0de30f1361dee7169bfb582fd619216c5bf93f88 and add the source of a record to the specific item in `recordItemsAll`. The source can be determined from the fetch url and config. Our config for the service base url option looks like this: ```yaml service_base_url: - url: https://pool.v0.trr379.de/api/protected/ type: write - url: https://pool.v0.trr379.de/api/public/ type: read ``` So from the fetch url we can get the element in this array, and extract the associated `type`, and we take the (implicit) convention that `write` is `protected` and `read` is not. This is brittle, so we need a better way to map this in future... So for data coming in from the backend we can log the source. And for data created or edited in the app we set the source to `protected` explicitly. And then we can e.g. show a lock icon when an item has the `protected` source, like this: ![Screenshot 2026-06-28 at 23.52.16](/attachments/4433f7e8-c621-440a-a2f9-a07d2094d8e3)

Screenshot 2026-06-28 at 23.52.16.png

136 KiB

🚀 1

adina commented

2026-06-29 13:29:49 +00:00

Owner

out of curiosity, what would happen if parts of a record (e.g., a single property) come from protected?

out of curiosity, what would happen if *parts* of a record (e.g., a single property) come from protected?

adina commented

2026-08-05 13:26:32 +00:00

Owner

I'm adding onto this issue and my last comment with updated information from the pool. I've posted to Matrix, and copy my message here for posterity:

Now that (public) publication records can link protected person records, we can experience how records look when one can only see partial information. E.g., take a look at https://pool.psychoinformatics.de/ui/?sh%3ANodeShape=xyzri%3AXYZPublication&pid=xyzrins%3Apublications%2F2224c455-0fb1-4eb5-93db-7bdd9cfd6d75 without a token set, specifically the 'attributed_to'. You'll see the person pids, but they don't resolve. For somebody without the right token, this is indistinguishable from genuinely not-resolving or malformatted pids. I was also wondering: in a sense the identifiers could leak information (if one is really keen), e.g., you could cross-reference common authors by their pid with several publication records. Its not really a relevant leakage for author information, but could it be an issue in other contexts? In any way, both visually/UX-y and from such a cross-reference perspective, it would be a big improvement if the editor had the ability to turn the unresolving pid into something like a little 'lock' sign, or something that clearly says "there is valid information here, but you're not authorized to see it"

@msz chimed in, too:

I looked, just at the level of browser's network monitor, at the requests being made (no token). Both persons/simon-eickhoff and persons/ae7f5e91... come back as 403 (from protected) and as 200 (from public); the difference in 200 responses is in the body (persons/ae7f5e91... only contains null).

I don't know the implementation details, but I guess it would be possible for dump-things to differentiate between 403 Forbidden (maybe also 401 Unauthorized) and 404 not found, and for shacl-vue to act on it.

I suppose the "standard" threat to consider would be the ability to check for existence of private records. With random UUIDs this shouldn't be much of a problem but maybe? Cross-referencing authors on a publication is kind of possible already.

> I'm adding onto this issue and my last comment with updated information from the pool. I've posted to Matrix, and copy my message here for posterity: Now that (public) publication records can link protected person records, we can experience how records look when one can only see partial information. E.g., take a look at https://pool.psychoinformatics.de/ui/?sh%3ANodeShape=xyzri%3AXYZPublication&pid=xyzrins%3Apublications%2F2224c455-0fb1-4eb5-93db-7bdd9cfd6d75 without a token set, specifically the 'attributed_to'. You'll see the person pids, but they don't resolve. For somebody without the right token, this is indistinguishable from genuinely not-resolving or malformatted pids. I was also wondering: in a sense the identifiers could leak information (if one is really keen), e.g., you could cross-reference common authors by their pid with several publication records. Its not really a relevant leakage for author information, but could it be an issue in other contexts? In any way, both visually/UX-y and from such a cross-reference perspective, it would be a big improvement if the editor had the ability to turn the unresolving pid into something like a little 'lock' sign, or something that clearly says "there is valid information here, but you're not authorized to see it" > @msz chimed in, too: I looked, just at the level of browser's network monitor, at the requests being made (no token). Both persons/simon-eickhoff and persons/ae7f5e91... come back as 403 (from protected) and as 200 (from public); the difference in 200 responses is in the body (persons/ae7f5e91... only contains null). I don't know the implementation details, but I guess it would be possible for dump-things to differentiate between 403 Forbidden (maybe also 401 Unauthorized) and 404 not found, and for shacl-vue to act on it. I suppose the "standard" threat to consider would be the ability to check for existence of private records. With random UUIDs this shouldn't be much of a problem but maybe? Cross-referencing authors on a publication is kind of possible already.