Waarom wordt lockId van bestandsdelen teruggegeven in enkelvoudiginformatieobject_list en enkelvoudiginformatieobject_retrieve?

[basretera]

Waarom wordt de hash string van de lock (lockId) teruggegeven in de response van enkelvoudiginformatieobject_list en enkelvoudiginformatieobject_retrieve? Dit is mijns inziens een beveiligingsrisico.

Op deze manier kan iedere gebruiker/applicatie toegang krijgen tot het object in editmodus.

Stel applicatie A lockt het EIO t.b.v. een nieuwe versie van het document te uploaden middels bestandsdelen. Aangezien het een groot bestand is, gaat er een tijd overheen dat alle bestandsdelen zijn aangeboden en verwerkt door de DRC. In de tussentijd vraagt applicatie B het EIO op. Deze applicatie ziet nu gewoon het lockId van applicatie A. Dit kan niet de bedoeling zijn. Het enige dat applicatie B zou moeten zien is dat het EIO is gelocked, en daar is attribuut 'locked' voor bedoeld.

Dit issue is gerelateerd aan #2293, #2336, #2337 en #2360.

[HenriKorver]

Goede vraag. Ik weet ook niet waarom de lock id van bestandsdelen wordt teruggegeven in bevragingen op EIO. Ze zouden m.i. alleen teruggegeven moeten worden in de responses van POST, PUT en PATCH operaties zodat ze alleen zichtbaar zijn voor de client die ze nodig heeft om een bestand in kleinere delen naar de server te kunnen sturen.

@michielverhoef: weet jij waarom deze lock id sinds versie 1.4.3 is toegevoegd aan de responses GET/GET List /Informatieobjecten?

[michielverhoef]

Ik vermoed dat dit een bug is. De lockid zou inderdaad niet getoond moeten worden in GET operaties.