HMACs do not match in URI

[Christopher Nagel]

Hi,

We're testing Finesse 11.6 ES10 and getting a weird error when loading gadgets that are hosted on a gadget server.  Visually, the "Loading" indicator turns into a "Retry" button, but this never works.  Looking on the network tab, it's a 400 Bad Request error, and when that URL is navigated directly, the following interesting error appears on a custom error page:

HTTP Status 400 - INVALID_USER_DATA concat(...)
ConcatProxyServlet.doGet() HMACs do not match in URI:

At the end of each concat? URL is a parameter called "code" and a fairly long number (e.g., code=379151f3506f09c24b3a3a56c7b5faffa76fee07). Is this the source of the error?  I notice it's different for each gadget requested.  Is there a timing issue?  I've cleared all my cookies, and the number is changing so I don't think it's stale data.

Is there a server log I could look at to get more information?  [Edit: catalina.out has the Shindig error messges essentially equivalent to the error page, no help in rectifying.] Anything in the CLI to help isolate this or rectify? Where are the concat URLs generated? Is it client code or something generated by a JSP on Tomcat?

Thanks!
Chris

[dekwan]

Hi,

When you say "when that URL is navigated directly, the following interesting error appears...", does that mean that you put the gadget URL into the browser and get that error? If so, it seems like the issue is independent of Finesse so I would focus on the logs on the gadget server. I am assuming that when you say gadget server, it is on a separate web server. Have you tried hosting that same gadget on the Finesse server? Does it give the same error?

Thanx,

Denise

[dekwan]

Hi,

Thank you for the clarification. My assumptions were completely wrong. What version did you have before upgrading to ES10?

---

@Christopher Nagel wrote:

I need to review the ES10 release notes to see if anything related to this part of Shindig was touched

---

I don't see anything that is specifically Shindig for the delta between ES9 to 10. I see a lot of changes for CORS and SSO.

---

@Christopher Nagel wrote:

Can you suggest to me where I can set a breakpoint in the Finesse startup process to see where/how the gadget URL is requested by the container?

---

Unfortunately I haven't done this myself, so I am not 100% sure, but I would suggest finding the part where the Finesse container requests the desktop layout via API. It must be sometime after that.

---

@Christopher Nagel wrote:

Note: this was a working installation prior to ES10, and the environment is based on load-balanced gadget/web servers, so I have not re-hosted the gadget on Finesse. Is there specific diagnostic data I can obtain by doing so? Is the separate web server architecture being deprecated?

---

No, you do not need to re-host the gadget. The separate web server architecture for hosting gadgets is not being deprecated.

Thanx,

Denise

Thanx,

Denise

[Christopher Nagel]

Hi Denise!

I think it was roughly 11.6(?)/ES3. Yes, I noticed the CORS changes but I'm not thinking that's impacting the Shindig URI hash. The gadget that is having issues is the only one we use CDATA instead of a separate HTML file, so I'm now separating them as a possible solution (although, TBH, it's probably busy-work to let my mind rest since it's the URI and not the body that seems to be at issue).

Good point about the container request - that's an excellent spot to start from! I'll letcha know what I can find! :-)

Thanks again!
Chris

[dekwan]

Hi,

---

@Christopher Nagel wrote:

I think it was roughly 11.6(?)/ES3. Yes, I noticed the CORS changes but I'm not thinking that's impacting the Shindig URI hash.

---

I looked through the changes in all of the ES's and I didn't see anything that stood out as a shindig change. Maybe there is something underlining that isn't obvious from the bug list headlines.

You can get the previous version you upgraded from by using "show version active" on the CLI. It might help pinpoint the issue.

---

@Christopher Nagel wrote:

The gadget that is having issues is the only one we use CDATA instead of a separate HTML file, so I'm now separating them as a possible solution (although, TBH, it's probably busy-work to let my mind rest since it's the URI and not the body that seems to be at issue).

---

So are you saying that you have other gadgets hosted at the same location that are working? It is just one out of many that is not working?

Thanx,

Denise

[Christopher Nagel · Accepted solution]

Hi Denise,

Yes! Just one out of 23! 2 or 3 others have minor anomalies, but I think those are just uncaught IE incompatibilities. :-\ 

I converted the one non-loading gadget from CDATA in the gadget.xml to an href="gadget.html" and — to my astonishment — it's now loading and working fine! I honestly had no expectation of success, but either something's up with resource references in a CDATA section's Shindig-assembled URI's or I accidentally fixed a reference while converting (although the gadget was not previously broken).  I'm sad I cannot say for sure.  But it's now loading and working!

Thanks so much for your help, and sorry the resolution isn't super specific.

Chris

[dekwan]

Hi,

I'm glad you were able to resolve your issue!

Thanx,

Denise