I managed to reproduce your problem in a test case. It seems that the XML parser that we use handles xi:include resolution and it does not invoke the URIResolver. The URIResolver hit that you got was to generate the target for the link icon rendered near the xi:include element. I registered an issue to use the URIResolver also in this case, but is not yet scheduled.
I think that a more robust solution would be to follow the approach described here .
If you want a simplified version, you can try to encode the auth token in the "userInfo" part of the URL.
For example, instead of "https://localhost:25608/Editor?Componen ... =authtoken
" use an URL like "custom-https://authtoken@localhost:25608/Editor?ComponentId=id
". Now, if you implement an URLStreamHandler for "custom-https", you should be able to make the same requests as before, but you do not depend on URIResolver to be invoked for every URL used by the application.
Another possible path would be to use "ro.sync.exml.workspace.api.util.XMLUtilAccess.addPriorityEntityResolver(EntityResolver)" to register an EntityResolver. This EntityResolver is called after the xi:include target is resolved (without using the URIResolver). If you use an URL like: "https://authtoken@localhost:25608/Edito ... =authtoken
", the EntityResolver will receive ""https://authtoken@localhost:25608/included.xml
" and now you should have all the data required to construct the final URL.
 https://www.oxygenxml.com/doc/versions/ ... _auth.html