Wednesday, December 27, 2017
Spiceworks HTTPS Redirect Breaks Stuff
Spiceworks HTTPS Redirect Breaks Stuff
We recently moved our Spiceworks installation to HTTPS. While theres a handy setting in the options to force user connections to the portal to use HTTPS, this doesnt affect the backend used by admin and helpdesk staff. Theres a lot of bad advice out there about how to accomplish this redirect. Many threads like this one suggest adding a 302 redirect to a port 80 virtualhost to redirect to https. While this does appear to work initially you will find that incoming emails no longer generate tickets. If you view the production.txt log in C:Program Files(x86)Spiceworkslog youll see an entry like this:
I[08:12:09.44 9b1030] scheduled call to check for ticket email url_ping: /tickets/check_email (http://127.0.0.1:80/tickets/check_email)Yep, thats right - Spiceworks uses an internal API on port 80. Whats worse is that it does not follow the 302 redirect correctly, so if you go this route it will not work. Luckily there are a number of other threads like this one on the Spiceworks forum that have a better suggestion - using Apache mod_rewrite to accomplish the task. Specifically you will need to add the following directives to the httpd.conf file in C:Program Files(x86)Spiceworkshttpdconf:
W[08:12:09.44 9b1030] check for ticket email url_ping: /tickets/check_email => unexpected response: Net::HTTPMovedPermanently
RewriteEngine OnThis will also require that you have the directive:
RewriteCond %{REMOTE_HOST} !^127.0.0.1
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
LoadModule rewrite_module modules/mod_rewrite.sosomewhere in the config but this appears to happen by default. Essentially this will rewrite any HTTP requests to HTTPS with the exception of 127.0.0.1, the loopback addressed used by Spiceworks for internal API calls.
