Question
· Nov 21, 2021

Private Web Server: FQDN vs. Host name Issue

Running HealthConnect 2021.1 on RedHat Linux 8.4.

I've configured IRIS/HealthConnect with an external web server to support TLS encryption. It's installed on the same server as IRIS, but is a different instance and version of Apache httpd. That all works as expected.

I would also like to keep the "private" web server available, but I'm having an issue with using the fully-qualified domain name in the URL vs. just the hostname itself.

If I use http://servername:52773/csp/sys/UtilHome.csp to log on, all is well.

If I use http://servername.domain.name.tld:52773/csp/sys/UtilHome.csp, The login page displays, but a logon attempt simply reloads so quickly it's like I never left, and I can't seem to get past it.

I'm not seeing anything in IRIS' application log, mgr/messages.log, httpd/logs/error.log or httpderr, csp/bin/CSP.log (logging level ev9r) or /var/log/messages; there's nothing about failed authentication in the audit table either. I'm pretty sure the issue is related to the private web server configuration and not IRIS itself, but it's using the default httpd/conf/httpd.conf. 

The really weird thing is that I have 4 other servers (2 mirrored pairs) that I've recently configured where this is not an issue at all. The private web servers work fine with either the FQDN or just the host name.

Has anyone else run into this?

PS. Yep, I'm aware of the security bulletin re: the private web server. I just want to make sure it will work in the event the standalone web server is for some reason unavailable.

Product version: IRIS 2021.1
Discussion (7)2
Log in or sign up to continue

Hi Robert! I'm not sure how this addresses my issue ...

I don't think it's a DNS problem. The IP address resolved is the same regardless of whether the domain portion is appended to the hostname or not. And as I said, I have 4 servers with identical local httpd configurations that work fine, and they're all using the same name resolution servers.

The only thing I could find that's different is that the iris.cpf file for the problem servers had a FQDN specified for the WebServerName entry while the working ones had no host specified at all. But changing the entry on one of the problem servers and restarting it made no difference.

Another note on this - there are some new behaviors in recent IRIS versions around the SameSite flag on cookies. (see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/Sam... for general background and https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls... for an explanation of the IRIS changes). This can make cookies behave differently in iframes, doing HTTP redirects, even opening via a link; how you get to a page has a bearing on cookie behavior.

Not sure if that fed into the issue you saw but it's worth noting.