--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.
Doesn’t matter. The certs are matched against the hostname with no attempt to resolve any sort of aliases or anything.
Anyway, localhost really ISN’T the same as foo.school.edu or foo.school.ac.uk or whatever, since those are handled by different network interfaces. So your FQDN address goes through DNS resolution to get to the IP address using (usually) eth0 or en0, whereas localhost translates to 127.0.0.1 (IPv4) or ::1 (IPv6) and goes through the loopback interface lo0.
Which is a little bit of angels on the head of a pin, but has the very real effect that you’re seeing there…
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.
I agree with your basic point, but unfortunately the Java security libraries don’t J
There is, however, a workaround for this. In the file WEB-INF/conf/services.properties, there’s a setting:
security.channel=any
If that’s set to any (other options are http and https) you can address the server through http or https. That means you can use http://foo.school.ac.uk OR https://foo.school.ac.uk. Any enforcement of https at the Apache proxy level is of course outside the scope of that control (we have nothing to do with it), but the upshot is that you should also be able to do https://foo.school.ac.uk OR http://localhost (you can also get around any Apache front-end redirects to https by going straight to Tomcat, e.g. http://localhost:8080 or http://localhost:8080/xnat).
Your other option, of course, is to use the FQDN with https even for the pipeline REST calls, which is actually what is recommended by most security experts (e.g. EFF has a typically stern and finger-wagging post about the topic here: https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory), although there’s no real danger with localhost being hijacked for man-in-the-middle attacks…
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
From: xnat_di...@googlegroups.com [mailto:xnat_di...@googlegroups.com]
On Behalf Of Simon Doran
Sent: Thursday, December 12, 2013 1:50 PM
To: xnat_di...@googlegroups.com
Subject: [XNAT Discussion] Re: SSL certificate problem with pipeline
Rick,
Technically, yes, but my point is that it is the same bit of hardware! Our SSL certificate is necessarily generated for the DNS hostname foo.school.ac.uk so that external people can access it! How do I convince pipeline to run the task on foo.school.ac.uk and not localhost and so avoid this problem? What do other people do?
Simon
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/groups/opt_out.
Simon
Can you post the entire call to the failed pipeline. I suspect you have an argument called alias_host which is being used.
Mohana
--
The host argument is picked up from Xnat Site configuration setting. Login to your Xnat instance as admin and change the site url.