Question
Jeffrey Drumm · Nov 21

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
00
2 0 7 85
Log in or sign up to continue

a typical feature of DNS resolution is caching of the translations
of servername.domain.name.tld or servername to IP addr.
so the resolution is just done once.
And a clever DNS would detect "oh it's me"
 

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.

Is anything going on with browser session cookies that might cause this?

Do you get the same problem if you access the private webserver via FQDN from, say, Chrome and via unqualified hostname using, say, Firefox? Or use incognito mode?

Of course! Browser Caching could be a beast.
I remember CSP or ZEN testing when I couldn't get rid of the old cached image version

Yikes, it appears to just that, John. Chrome worked fine for the other servers, but not the two mentioned above.  Switching to Incognito mode, I was able to sign on using both the FQDN and just the hostname. And after clearing cookies/cache, normal mode works as well.

Gah, rule number 1 of web troubleshooting and I completely spaced on it.

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.