I have installed Knime server small 4.7.3 on a node in AWS. The node is always accessed via VPN, but when I access it via the configured DNS hostname, I can’t access the Administration section - clicking on “Administration” in the UI immediately presents you with the user authentication screen. A tcpdump taken at the time shows a 404 on trying to load a CSS file:
172.29.X.X - knimeadmin [28/Jun/2019:18:41:07 +0000] “GET /admin/VAADIN/themes/knime/styles.css HTTP/1.1” 404 1119
Accessing it via IP address does not have this issue and no 404 appears in the tcpdump. Can anyone help me figure this out?
Weird. I wonder if that could be related to the CSRF prevention setting:
https://docs.knime.com/2019-06/server_admin_guide/index.html#csrf-prevention
Stopping the server, and changing the settings as described, then starting the server and trying should be able to rule that suspicion in or out.
Am I correct in thinking that you built and installed the image yourself, rather than using the images available from the AWS Marketplace?
Yeah, we’re not using an AMI - I just downloaded Knime from the official site and used the GUI installer on an EC2 instance, then added our license key.
There is no file on the disk called “knime.xml”, and doing a recursive grep through the entire tree that knime is installed in doesn’t show any csrf settings to change, so I’m not sure if I just need to create the file and add that configuration or if I’m on some different version where the setting exists in an alternate location.
If you access your KNIME Server at https:///knime then the file will be found in /conf/Catalina/localhost/knime.xml
If you access the server with a different context root, e.g. https:///example then the file will be called example.xml
I’m not sure why our setup seems so different from your expectation, but the only conf directory I can find is /data/knime_server/apache-tomee-plus-7.0.5/conf, and there is no xml file beginning with the hostname of the machine or the name by which we access Knime (knime01) anywhere on the file system. I did a recursive grep from the root of the filesystem for any file containing ‘csrf-protection’ and nothing was found.
I snagged the graphical installer from the Knime site and generally accepted the defaults, with the only exception being that everything is installed on a larger EBS volume mounted at /data/, so all paths are relative to /data/knime_server. The installation was performed over VNC on a CentOS 7.5 instance, and other than setting up a few users and test jobs, no changes have been made.
The file should be a directory in /data/knime_server/apache-tomee-plus-7.0.5/conf/Catalina/localhost/knime.xml
Best,
Jon
The filename ended up being ROOT.xml - thanks for the assistance finding it.
I added the config line to disable CSRF protection and restarted apache-tomee, and the behavior hasn’t changed.
I also updated from 4.7.3 to 4.8.x and then to 4.9.0 in hopes of resolving it that way, and it did stop happening to me for the remainder of Tuesday - but since then the issue has returned.
It feels like some kind of caching problem, but I don’t know where to configure cache longevity or anything of that nature.
Possibly related, we frequently get 408 errors upon initial login until we force a fresh load of the page with shift-F5. Is there a straightforward method of disabling or minimizing the usage of browser caching?
Well, I added cachingAllowed=“false” to the server.xml file and restarted. I guess we’ll see if that helps over the weekend.
I did find that the issue with accessing the admin page is resolved at least temporarily with a shift-F5 when presented with the login screen after attempting to access the admin page, so it really does seem to be cache-related.
Hi @envysionit,
Any update on this? I have not come across caching issues related to this, so would be interesting to see what causes this.
Cheers,
Roland
I’m still able to access the Admin settings page now, without having to clear my cache first. So, I think the issue is likely just cache-related in its entirety.
If it pops up again I’ll reply to this thread, but it appears resolved now by disabling caching on the server.
Great, thanks for sharing your solution! 
