IBM SBT: CommunityService.updateCommunityLogo(file, communityUuid) triggers logout? - ibm-sbt

Question

I (want to) use CommunityService.updateCommunityLogo(file, communityUuid) to set a logo for a freshly programmatically created community.
The call runs though without error, but the logo is not changed.
When I look into the apache.http.wire logs, it shows following conversation:
>> PUT /communities/service/html/image?communityUuid=6e700c5d-082c-497f-8657-d516a01f62e7 HTTP/1.1 (without data so far)
<< HTTP/1.1 100 Continue
>> (binary data of image)
apache.http.wire(78): << "HTTP/1.1 100 Continue[EOL]"
apache.http.wire(78): << "[EOL]"
impl.conn.DefaultClientConnection(229): Receiving response: HTTP/1.1 100 Continue
apache.http.headers(232): << HTTP/1.1 100 Continue
apache.http.wire(78): << "HTTP/1.1 200 OK[EOL]"
impl.conn.DefaultClientConnection(229): Receiving response: HTTP/1.1 200 OK
apache.http.headers(232): << HTTP/1.1 200 OK
apache.http.wire(64): << "<script language="JavaScript1.2">[\n]"
apache.http.wire(64): << " document.cookie = "CommunitiesReqURL=" + location.href + "; expires=" +[\n]"
apache.http.wire(64): << " new Date(new Date().getTime() + 365*24*60*60*1000).toGMTString() + "; path=/communities";[\n]"
apache.http.wire(64): << " location.href = "/communities/service/html/login";[\n]"
apache.http.wire(64): << "</script>[\n]"
I have skipped some details like Date, Content fields etc. from header and wire, but this is what basically happens.
This in turn is part of a request processing from inside a web application which should automatically do some things on a Connections instance. Thus, as a result, this web application will present the answer to the original user request to the user as a web page. This in turn contains a frame with the community which was changed here -- but after this step the user is forced to login anew on Connections (although the LTPA token is "fresh") in full-window mode.
Thus I suspect that calling CommunityService.updateCommunityLogo(file, communityUuid) forces re-authentication and destroys/invalidates the current LTPA token or authenticated session.
What is happening here?
What can I do about it?
Remarks:
I have no access to any Connections logs actually.
The Connections instance is v4.5 and directly accessed using BasicAuth in IBM SBT, but uses form-based auth in the browser.
The SBT version is 1.0.2.20140527-1807, included using maven 3.0.5, deployed on tomcat 7.0.53 on Java 7.

Answer 1

it's actually most likely related to the 100 continue for that API
I wrote an article on it http://bastide.org/2014/06/19/expect-100/
For J2EE Apps, navigate to your managed-beans.xml. Locate the Endpoint you want to disable it for, add a managed-property.
forceDisableExpectedContinue
true
some sample code I wrote for this...
public static void main(String[] args){
URL url;
try {
String imageUrl = "https://servername.com/communities/service/html/image?communityUuid=1e244250-6740-4949-aaac-682707a47099";
String imageType = "image/png";
String folder = "/Users/paulbastide/Desktop/";
String fileName = "demo.png";
File file = new File(folder + fileName);
long fileLength = 0l;
String userAgent = "Apache-HttpClient/4.3.3 (java 1.5)";
String auth = "Basic =";
url = new URL(imageUrl);
HttpsURLConnection httpCon = (HttpsURLConnection) url.openConnection();
httpCon.setDoOutput(true);
//https://code.google.com/p/misc-utils/wiki/JavaHttpsUrl
// Create a trust manager that does not validate certificate chains
final TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() {
#Override
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
#Override
public void checkClientTrusted(
java.security.cert.X509Certificate[] arg0, String arg1)
throws CertificateException {
// TODO Auto-generated method stub
}
#Override
public void checkServerTrusted(
java.security.cert.X509Certificate[] arg0, String arg1)
throws CertificateException {
// TODO Auto-generated method stub
}
} };
// Install the all-trusting trust manager
final SSLContext sslContext = SSLContext.getInstance( "SSL" );
sslContext.init( null, trustAllCerts, new java.security.SecureRandom() );
// Create an ssl socket factory with our all-trusting manager
final SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
httpCon.setSSLSocketFactory( sslSocketFactory );
/**
* adds the cookies
*/
httpCon.setRequestProperty("Cookie", "");
// Responds to two operations PUT and DELETE
httpCon.setRequestMethod("PUT");
httpCon.setRequestProperty("Content-Type", imageType );
httpCon.setRequestProperty("slug", fileName);
httpCon.setRequestProperty("Content-Length", "" + fileLength );
httpCon.setRequestProperty("Content-Encoding", "binary");
httpCon.setRequestProperty("User-Agent", userAgent);
httpCon.setRequestProperty("Authorization", auth);
byte[] fileBytes = FileUtils.readFileToByteArray( file);
DataOutputStream out = new DataOutputStream(
httpCon.getOutputStream());
out.write(fileBytes);
out.close();
httpCon.getInputStream();
System.out.println("The Response Code is " + httpCon.getResponseCode());
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (ProtocolException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (KeyManagementException e) {
e.printStackTrace();
}
}

Answer 2

IBM SBT SDK 1.0.3 solves this problem: Tests with the same application code and 1.0.2 / 1.0.3 revealed that 1.0.2 is buggy here, but in 1.0.3 this issue is fixed.
Additionally however the server side has undergone an upgrade from IC 4.5 to IC 5.0, but with the 1.0.2 IBM SBT SDK also IC5 did not accept the logo. Thus it might be both: IC45 -> IC5 AND SBT 1.0.2 -> 1.0.3.