我没有使用 SBT，而是使用 Abdera 对 IBM SmartCloud 上的当前版本的 Connections 进行直接 REST 调用。有问题的 REST URL：https ://apps.na.collabserv.com/search/serviceconfigs
观察
在我的笔记本电脑上进行测试（使用 Firefox 和 REST 客户端插件）时，它可以按预期工作。我得到了一个 ATOM 提要。
当使用相同的方法（Firefox + REST 客户端）从服务器（在不同的网络上）进行测试时，我得到了作为登录页面的 HTML。
此外，当我从同一服务器上的 Java 程序调用 URL 时，我得到了同样的结果。
在所有情况下，我都使用具有基本身份验证的相同凭据。
更新：如果我首先登录 SmartCloud，在服务器上 Firefox 的一个单独选项卡上，然后像以前一样从另一个选项卡调用 URL，它可以工作。我根据需要获得了 ATOM 提要。当然，这不适合作为解决方案，但我将其作为可能导致实际解决方案的附加信息呈现。
更新：进一步的测试表明本地（笔记本电脑）登录表现出与服务器相同的行为。需要从同一个浏览器进行基于表单的登录，然后后续的 REST 调用才能工作。
更新：这是一个相关的简化代码片段：
private static Abdera ABDERA = new Abdera();
private static AbderaClient ABDERA_CLIENT = new AbderaClient(ABDERA);
...
String host = "https://apps.na.collabserv.com";
ABDERA_CLIENT.addCredentials(host, AuthScope.ANY_REALM, "basic", new UsernamePasswordCredentials("user", "password"));
...
ClientResponse response = ABDERA_CLIENT.get("https://apps.na.collabserv.com/search/serviceconfigs");
概括
似乎与始发服务器或呼叫有关的某些事情导致 SmartCloud 以登录页面响应。然而，来自我的笔记本电脑的相同呼叫和凭据按预期工作。
问题
我应该从哪里开始解决这个问题？如何构建客户端凭据以允许以编程方式登录？
响应标头
如果有帮助，这是我在每种情况下返回的响应标头。
不成功
Status Code: 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 1850
Content-Type: text/html
Date: Tue, 08 Oct 2013 14:15:03 GMT
Pragma: no-cache
Server: WebSEAL/6.1.1.3 (Build 110428)
Set-Cookie: PD-H-SESSION-ID=4_0_IR4***masked***oRKlJI;secure; Path=/; HttpOnly BIGipServerE3A-WebSEAL-80-fe=2132806922.20480.0000;secure; path=/
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
成功的
Status Code: 200 OK
Cache-Control: public, max-age=86400, s-maxage=86400, no-cache=set-cookie, private, must-revalidate
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 1164
Content-Type: application/atom+xml; charset=UTF-8
Date: Mon, 07 Oct 2013 17:21:12 GMT
Expires: Tue, 08 Oct 2013 17:21:12 GMT
Server: WebSphere Application Server/8.0
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-lconn-auth: true
x-powered-by: Servlet/3.0