NIFI-3207: Incorrect URI generated when replicating Template upload request

[mcgilman]

NIFI-3207

• Fixing the importUri when replicating a Template upload request. Previously was leveraging getResourceUri which considers proxy headers meant for client responses.

[rstjohn]

After further testing of this Pull Request, I noticed a User-interface issue in Chrome that does not exist in Firefox or Safari. In Chrome, from the templates dialog, the "trash can" is missing. As such, I am unable to delete previously imported or saved templates. Here is a screenshot from Chrome. Note that the div is present, but not visible.

And here is the same screenshot from Firefox.

Here is Safari:

[mcgilman]

Thanks for checking back and providing these details. I think the button is wrapping to the next line. We've seen this sort of thing in the past. In fact, we just merged in a PR that addressed this in a few of the other tables. However, the issue has never been in Chrome. It's typically been with a different browser. Chrome seems to be rendering it ok for me right now.

Can you verify that the browser is not zoomed in at all? You should be able to go to View -> Actual Size and see if the button shows up again. Let me know if this doesn't help.

[rstjohn]

Unfortunately, the browser is not zoomed when this occurs. The issue is far more convoluted than that. It appears that the issue is related, somehow, to the nginx reverse proxy issue. The delete button is missing only when the nginx proxy is used. If I connect to the NiFi cluster without the nginx reverse proxy, the button is visible and functional.

[mcgilman]

Thanks for the feedback. That button is present based on the users permission to modify the template [1]. Looking at the screenshot, the button has been added to the DOM so the permissions to the template are correct. I believe the button has just wrapped to the next line. Now the question is why has this happened.

Let's try to eliminate one other simple possibility first. The templates page is loaded via an iframe. This can sometimes cause caching issues. Resources are cached according to URL so if you access the instance differently (different scheme, host, or port) when bypassing the proxy, this may be what's happening. Opening the templates page directly (outside of the iframe) will allow you to clear the cache. This doesn't happen reliably when loading through an iframe.

Can you try popping the page out by clicking the arrow button next to the close 'X' in the upper right-hand corner of the shell? Once the page is in it's own page/tab can you clear the cache or do a hard refresh to see if that makes a difference?

Thanks.

[1] https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui/src/main/webapp/js/nf/templates/nf-templates-table.js#L265

[rstjohn]

Great job debugging the issue. It was, in fact, what you suspected: a caching issue. I was able to remedy the UI by extracting the template iframe into a separate tab. Then, I cleared the cache and did a hard refresh. After that the delete button was visible. Lastly, I refreshed the NiFi canvas and viewed the templates inside the iFrame and the delete button was visible. Thanks for taking the time to get this resolved.

[ijokarumawak]

Reviewed the change, all looks good!

I was able to reproduce the issue on a docker environment with an un-secure NiFi cluster running behind a nginx which terminates SSL. Docker-compose file is available here.
Then, confirmed that a template file can be uploaded after applying this PR.

Also, I double checked the usage of isReplicateRequest() and getRequestReplicator() methods. Confirmed that ProcessGroupResource.uploadTemplate() is the only one that construct URI without using uriInfo.

Thanks for reporting this issue, @rstjohn , and the fix, @mcgilman !
I'm merging this into master.