HTTP 408 from j_security_check when dashboard embedded

KNIME Server
1

Hi,
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

2

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?

3

At times Chromes rather aggressive caching can cause these kind of problems. Does the problem persist even after opening a new session, incognito session or after hitting Ctrl + Shift + R?

4

Hi Marten,
Thanks for replying.
Yes, it blocks in the same way incognito. We can see in dev console the cookie isn’t sent when strict (default) handling is applied by the browser, so it’s not surprising the server doesn’t know which session it’s dealing with.
We’re planning to upgrade to 4.12 very soon, so planning to re-test when we get our pre-prod server up and running.

5

Hi @underhillj,

thanks for all the input. We are currently investigating on possible solutions for this. The main problem is that the cookie is blocked by many browsers. Updating to 4.12 does not resolve this limitation. I’ll keep you posted on any news on this topic.

6

Has anyone been able to fix this? I’m facing exactly the same issue when embedding a JSF application in a web portal.

Thank you.

7

Hi @jeferson_dmolin as this is a fairly old discussion regarding a version 4.12 KNIME Server which is no longer supported, we’d first like to ask what your current version is.