_type is higher priority than Content-Type

[abalmos]

Resources put with a _type key that value as the overall content type (in terms of scope checking at least) rather than the value given in the PUTs content-type header.

[awlayton]

Not sure what we should do in the case the two things disagree? We could error, but that feels too picky maybe?

[aultac]

Experience has shown me that type errors are a pain, so I am all for being as not-picky as possible :). I feel like if you have both and they disagree, you should use the content-type header as that is the “official” web-defined thing. This only matters on resource creation: after the resource is created, the content type and _type both have no effect because the scope and other checks are done against the type stored on the resource in the database, not the type on the header from the outside world. This is so that you can’t just grant your token permission to things by specifying content-type headers that you know you have permission to on resources that already exist as a content type. This also means we do not have a means currently to alter the content type of a resource after it is created: one has to make a copy w/ a new content type. Aaron

…

On Mar 12, 2021, at 11:59 PM, Alex Layton ***@***.***> wrote: Not sure what we should do in the case the two things disagree? We could error, but that feels too picky maybe? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2KEUG4A32KZYHCIRY57FTTDLPLXANCNFSM4KKMWIBA>.

[awlayton]

Does OADA really not allow changing the type of a resource? Yes the scope checks are against the current type not the one in the request, but if you are allowed to modify a resource you should be able to send a new type and have that take effect.

[aultac]

Well, I don’t know that we ever designed it to never allow changing the type of a resource, but the current code doesn’t allow it because the _ keys are stripped prior to writing. However, as time has gone along, it’s become apparent that the changing of a resource type in the graph actually carries significant problems for most listeners. The listeners listen down the graph, and changing a node above them in the graph could mean that their listener is no longer listening to the right place. This makes perfect sense if you change the _id of one of the upper resources because when the above resource is actually changed out, you’d expect your path to be invalid. I think _type change has equally difficult ramifications to altering the graph with a new resource. If we leave things as they are now (can’t change _type on a resource, have to make a new one), then just tracking the _id changes gets _type change tracking for free. Philisophically, I think this makes sense because a resource is a type of thing and you can’t change a dog into a cat. If you want to, you’re going to have to sell the dog and buy a cat :). So, I’m on the fence whether we want to allow changing the _type of a resource because I think it comes with a host of hidden gotchas that most people probably don’t want to deal with and therefore the inability to change _type on a resource is less total frustration than being able to change it. Leaning toward just leaving it as not allowed, but open to allowing it. Aaron

…

On Mar 14, 2021, at 6:08 PM, Alex Layton ***@***.***> wrote: Does OADA really not allow changing the type of a resource? Yes the scope checks are against the current type not the one in the request, but if you are allowed to modify a resource you should be able to send a new type and have that take effect. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2KEUFAG2T57Z76E73E6OTTDUXWJANCNFSM4KKMWIBA>.