Problem
Error of authentication using TiNetworkHTTPClientProxy.m in http client under iOS 5
Reproducible steps:
1. Locate the TiNetworkHTTPClientProxy.m file in the next path:
/ Users/your_username/Library/Application Support/Titanium/mobilesdk/osx/ 1.8.0.v20111028154620/iphone/Classes/
2. Locate, and update the code of the file.
-(void)open:(id)args method implementation and add right after request initialization string (1) authorization strings (2 and 3), see below:
request = [[ASIFormDataRequest requestWithURL:url] retain]; (1)
[request setUsername:@"xxxxxx"]; (2)
[request setPassword:@"xxxxxx"]; (3)
Please go to the ticket(APP-915216) to see the setUsername, and setPassword.
3. Run the code below.
Expected behavior:
Customer wants to keep the same behavior of iOS 4.3 in the 5 iOS SDK version.
Sample code:
var miwin = Ti.UI.createWindow({
backgroundColor : 'white'
});
var xhr = Titanium.Network.createHTTPClient()
xhr.timeout = 30000;
xhr.open('GET', 'https://ios.plainscapital.com/_vti_bin/listdata.svc/Locations?$select=Id,Title,Latitude,Longitude,City,StateProvince');
xhr.onload = function() {
alert('succeed');
};
xhr.onerror = function(e) {
alert(e.error);
};
xhr.tlsVersion = Ti.Network.TLS_VERSION_1_0;
xhr.send();
miwin.open();
Additional info:
The application does not create any logs in the next path:
Library/Logs/CrashReporter/
Associated HD Ticket:
APP-915216
This is effectively the iOS-specific version of TIMOB-5435 (and may require an update to the ASI library as well). We need to provide API access to username/password (and domain) properties of ASI. This should provide the requested functionality.
Quick note; this bug appears to be due to the fact that iOS 5 no longer fires (kCFStreamEventEndEncountered) events to the read callback after an error occurs, as it previously did. This prevents the system from picking up the (401) error result and responding to the challenge appropriately. It could be a behavior change based on unrecognized certificate rejection.
It turns out that this is an error with the 3rd party library we're using, which currently has a bug report revolving around this issue: https://github.com/pokeb/asi-http-request/issues/273 Unfortunately, we are blocked on them being able to resolve this problem. Information about, and verification of, the relevant system serving the certificate may be necessary to provide further information to the 3rd party so that they can solve the issue faster. It could also be the case that there is a configuration error with the SSL certificate or serving process which is preventing the handshake from occurring correctly. We cannot resolve any configuration issues ourselves - only pass on information to assist in the resolution of bugs where possible. ---- We will still be able to offer new API points for username/password/domain as per TIMOB-5435, removing the need for custom modifications, but are waiting on internal testing infrastructure to verify the changes.
Ticket TIMOB-5973 indicates ASI is no longer under active development, meaning it needs to be replaced and we should not expect any fixes to come through that pipeline. We will be required to implement them ourselves.
Please see this technical note; this is likely a server configuration problem. http://developer.apple.com/library/ios/#technotes/tn2287/_index.html#//apple_ref/doc/uid/DTS40011309
Probably SSL versioning support as above.
Requires a retest with sslVersion set.