Trying to connect the BigFix Session Relevance Tester to our Web Reports server via HTTPS (we don’t allow non-SSL HTTP) and am getting the following error: The provided URI scheme “https” is invalid; expected “http”.
Is there a way to get the SRT working with HTTPS? I’ve installed version 8.0.627.0 … is there a newer version?
So, follow-up question: That post was from two years ago … any plans for an update that allows for th euse of HTTPS and the “Version 8 SOAP API” together?
We don’t have any current plans to update the session relevance tester. I’m not really familiar with it though. Is the main problem that it will not connect via https?
I am working on tracking down the source code for the Session Relevance Tester and hopefully will be able to open source it on https://github.com/bigfix. I will keep this thread posted when there is news.
I am using the Session Relevance tester with HTTPS, but I am not using the “Use Version 8 SOAP API” checkbox. Did you try using HTTPS without “Use Version 8 SOAP API” checked?
You can have multiple WebReports servers. I would stand up a test server that is version 9+ and see how well it works with your 8+ root server if you can’t upgrade everything yet. I would guess that the webreports 9+ server would work just fine, though I wouldn’t know without testing.
I guess what I am also getting at is, why do you need to “Use Version 8 SOAP API”?
Honestly, I’m assuming that the Version 8 SOAP API is better than the earlier version, perhaps more efficient. The Session Relevance Tester also defaulted to having “Use Version 8 SOAP API” turned on, if I recall correctly.
We’re running Version 9+ and things are working just fine.
another option would be to run a second webreports server for development and testing purposes and have webreports not open to any IPs and then use a VPN connection to the webreports server so that the HTTP traffic will be secured over the VPN between you and webreports.
Again, the HTTPS is working fine now. I am not part of the server management team for this service, so standing up another WebReports server is not an option. Thanks.