Re: [atlassian-connect-dev] Confluence instance ID available to a dynamic macro plug-in?

[Einar Pehrson]

Hi Michael,

have you set the authentication type to jwt in your descriptor? If so, you should be receiving a JWT token on the query string when viewing or previewing your dynamic macro, or in the Authorization header for PDF export.

Have you found a way to associate a Confluence user with the corresponding account in your service? There are different ways of accomplishing that.

Cheers!

Einar

On Tue, Feb 7, 2017 at 10:20 PM, Michael Eskin <seisi...@gmail.com> wrote:

I'm working on a plug-in where it would be very useful to have the Confluence instance ID available to the code loaded to the plug-in both for security as well as user account identification on our server side of the plug-in.

I've noticed that no JWT tokens are being provided (at least not on the URL parameters, haven't spelunked the authorization headers yet) when our plug-in is loaded either in edit, display, or PDF static generation render modes.

I do have lifecycle install and uninstall callbacks, and they are getting called, so I can get the instance then, but there is no way I can see when the user uses our plug-ins, which involve cloud storage in our infrastructure, to pair up the macro instance with their account, which ideally would be based on the Confluence instance ID and user_key.  

We get the user_key in the URL params, and could use that on our server side to match up to a Confluence instance, but according to Atlassian, those aren't guaranteed to be unique across Confluence install instances, so while there is probably a tiny chance of user_key collision, I'd really like to avoid it by design if possible.

The bigger issue is the static PDF render mode callback, with no JWT token being sent and no ability to run any Javascript (confirmed that this has to be a completely static page generated by our server based on URL parameters), about all we have is the user_key value on the URL parameters to identify the user, but no way to identify for sure the Confluence instance. 

To construct the static page, the hope is that we could, given the Confluence instance ID (which would be right there in the JWT token if it were passed, but could be based on user_key lookup which as I've described, problematic) and content ID in URL parameter, pull our custom content data from the Confluence instance with a REST call, construct and return the static page.  All hinges on closing the loop to match up the request with the proper Confluence instance that was previously registered at our lifecycle installed callback.

Anyone else dealt with this?  

Thanks,

Michael

--
You received this message because you are subscribed to the Google Groups "Atlassian Connect Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to atlassian-connect-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.