HTTP 408 from j_security_check when dashboard embedded

We have users reporting intermittent problems accessing the web portal (v4.9.2 on CentOS 7) when it has been embedded in a wiki page (iFrame pointing to the appropriate workflow in the portal). We can see the HTTP 408’s in the server access logs, but nothing relating to any cause in the other logs. Of course, we don’t seem to be able to reproduce the issue ourselves!

Log entries look like this:
10.XXX.XXX.XXX - - [17/Aug/2020:14:05:34 +0000] “POST /knime/j_security_check HTTP/1.1” 408 1231

Does anyone have any ideas for how we can further troubleshoot this?

User experience goes something like this:

  • Using Chrome 84.0.4147.89 (Official Build) (64-bit)
  • Accessing wiki page correctly shows the KNIME login screen in the iFrame
  • After entering credentials the HTTP Status 408 screen appears immediately
  • In a new tab If I open the web portal direct,the page loads fine
  • If I clear all cookies for my browser the problem persists
  • Alternatively if I open that same wiki page in Internet Explorer, the page loads successfully after entering credentials.

Thank you

We seem to have narrowed this down to the way Chrome handles cookies without SameSite attributes. The 408 seems to be caused because when Knime webportal is embedded in the iFrame, Chrome doesn’t return the JSESSIONID cookie because it’s following strict samesite rules.

If we use one of the development flags in Chrome to emulate “lax” behavior for cookies without samesite declarations, the embedding works fine.

Has anyone else been able to add samesite attributes to the cookies in v4.9.2? Or do we need to look to upgrade sooner rather than later?