'Share Docs' $ref does not work

[daida00]

Hello.
I am using apicurio studio.

If data types defined in other APIs are imported and used, an error occurs when calling 'Share docs'.

But, It works well when using 'Preview Docs..'.

[EricWittmann]

Thank you for the report. I think this might be a duplicate of #1417

[EricWittmann]

But I'll leave this open until I'm sure.

[daida00]

Thank you for your confirmation.
If the function works, it seems to be useful.

[jsenko]

hi, @daida00 version 0.2.49.Final is running on https://studio.apicur.io/ . Can you please check if the issue has been resolved?

[DyspC]

I think this is not resolved yet in 0.2.50 and am willing to fix it but from what I've seen so far there is no way to resolve apicurio: references from within the WS module because the InternalReferenceResolver asserts the user in the security context has read access to the design.

Perhaps dereferencing classes should be reorganized to move the ContentDereferencer and AbsoluteReferenceResolver to hub-core. That way we should be able to add a ReferenceResolver in the WS that uses the user who created the sharing link to resolve references using his ACLs.
It would only need a bit of DB tinkering to store the user somewhere but I think linking what the share servlet can resolve to who shared the resource makes sense.

[EricWittmann]

Could we assume that sharing a document using the Share Docs feature also implicitly implies that any $refs in the doc are also available? In other words, create a reference resolver that doesn't need a user. Does the storage layer require the user? I can't recall. :(

[EricWittmann]

Although perhaps that's a bad idea because it opens an attack vector whereby someone could manually add an apicurio: reference in their source and then do a ShareDocs on their api design. Thereby getting access to content they cannot see.

So nevermind. :)

I'm not sure I see another option other than storing the username of the user who shared the document and then fabricating a principal as you suggest.

[EricWittmann]

TLDR: So +1 from me on your proposal above, @DyspC

[DyspC]

I was thinking about the attack vector too, using who created the link does not fully close the hole because users with write access can extract specifications only the other can see but it makes it really less exploitable than just skipping all controls.

A more complete option would be to check if a quorum of the collaborators has access but it makes everything complicated and users will have trouble understanding why adding collaborators to a document breaks its documentation

FYI @EricWittmann I'll wait a bit before I add columns to a table since version 12 of the ddls is on its way (template publication)

We will also have an issue with existing documentation links whose creator will be undefined, how should we handle this?

[EricWittmann]

Good question - perhaps the DB upgrade script can populate the new column using the creator of the API design.

[daida00]

@jsenko
Thanks for checking.
I checked with version 0.2.50.Final, and the same error occurs.

[adrixgc]

I had the same error and managed to make it work by sharing first the referenced api. After that, sharing was possible.