Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-7470] iOS: Set TLS version for imageview

GitHub Issuen/a
TypeBug
PriorityMedium
StatusClosed
ResolutionWon't Fix
Resolution Date2012-05-31T13:35:46.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsiOS
Labelsn/a
ReporterMauro Parra-Miranda
AssigneeStephen Tramer
Created2012-01-30T10:54:40.000+0000
Updated2017-03-09T23:09:28.000+0000

Description

PROBLEM DESCRIPTION

Customer addressed an XHR issue we had using SSL on iOS5 against our test server. iOS5 uses TLS v1.2 by default and our server fails to negotiate v1.2. They used this: http://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Network.HTTPClient.tlsVersion-property.html and worked fine. The only issue is that they are getting images from the secure server with iOS5, will fail.

EXPECTED BEHAVIOR

The TLS configuration impacting the imageview url

ACTUAL BEHAVIOR

The image is failing to download in iOS5

TEST CASE

TEAMWORK DISCUSSION

https://appcelerator.teamworkpm.net/tasks/524931

Comments

  1. Blain Hamon 2012-02-06

    Image View gets their images through the image loader, which is a low level aspect. Image Views don't load images directly, so this would not be a property on each individual image view. There's a few options here. 1) Have global settings that can be set to lower the TLS version as a 'compatibility mode' for all images fetched. 2) allow an HTTPClient be bound to an imageView as an image source. Issues here involve that clients can only be opened once, and might be expensive. Either way, we'll have to look into this. I'm hesitant for short-term fix or creeping featurism that may prove expensive to maintain later on.
  2. Stephen Tramer 2012-02-06

    Believe it or not, the best solution might actually to be to use existing infrastructure to pull the image down from the remote source via an XHR client, and upon completion set it as the imageview's image (via a downloaded file - this has the convenient side-effect of even behaving like our internal image caching). Most developers will not be using TLS versioning to pull images from an HTTPS source so we should definitely be wary of bloat. Setting a TLS version globally runs the risk of errors or insecure communication when contacting multiple servers over HTTPS.
  3. Stephen Tramer 2012-02-07

    The following is the appropriate way to load images from secure resources. In general, when accessing resources over SSL, an HTTPClient is the "most appropriate" way to interact with the server, due to certificate validation and TLS versioning settings. In the future there may also be many more options which affect interoperability with SSL. As a bonus, it also gives finer-grained control over the "crossfade" animation we provide internally when loading a remote resource, as well as better cache control for downloaded images.
       var win = Ti.UI.createWindow({
       	backgroundColor:'white'
       });
       
       function loadRemoteImage(local, remote, imageProps) {
       	var file = Ti.Filesystem.getFile(Ti.Filesystem.applicationSupportDirectory, local);
       	var imageView = Ti.UI.createImageView(imageProps);
       	
       	if (!file.exists()) {
       		var imageLoader = Ti.Network.createHTTPClient();
       		imageLoader.open('GET', remote);
       		imageLoader.file = file;
       		imageLoader.onload = function(e) {
       			// Prep the image for crossfade
       			imageView.opacity = 0;
       			imageView.image = file; // Using imageLoader.file gives a path and there's some internal issues with path resolution
       			
       			// Manually crossfade the image
       			imageView.animate({
       				duration:500,
       				opacity:1
       			});
       			
       			// Clean up the XHR
       			imageLoader = null; // Clean up the XHR loader; do NOT use 'this'
       		};
       		// Change your TLS and certificate validation settings here
       		// imageLoader.validatesSecureCertificate = true;
       		// imageLoader.tlsVersion = Ti.Network.TLS_VERSION_XXX;
       	
       		imageView.image = "default" // The image: property needs to be set to a junk value so the "default" image displays.
       		imageLoader.send();
       	}
       	else {
       		imageView.image = file.nativePath;
       	}
       	
       	return imageView;
       }
       
       var imageView = null;
       if (1) { // Change to see Titanium loader behavior
       	imageView = loadRemoteImage('kitty.jpg', 'http://placekitten.com/200/300', {
       		width:"auto",
       		height:"auto"
       	});
       }
       else {
       	imageView = Ti.UI.createImageView({
       		width:"auto",
       		height:"auto",
       		image:"http://placekitten.com/200/300"
       	});
       }
       
       win.add(imageView);
       win.open();
       
  4. Stephen Tramer 2012-02-07

    Provided an example of an appropriate way to use HTTP and SSL to interact with remote resources.
  5. Blain Hamon 2012-02-08

    The one catch to the sample code is that in a large table view, you'll end up loading images long before they come onscreen, leading to a sudden rush and starving the ones actually onscreen. A more advanced solution would be to do the HTTP client creation and open on image load (IE, when the placeholder image loads) which would have the lazyloading that is optimal. Either way, it's possible that the best solution is not a modification to low level code, but a small JS library snippet that uses what's already there to provide results. It'd be portable, general purpose, and best yet return power to the developer to be able to tweak and tailor the code instead of waiting for a long term low level implementation. Isn't part of the reason for Titanium is that Javascript is powerful enough on its own, and flexible enough to provide solutions?
  6. Stephen Tramer 2012-05-31

    Sorry, but we're still not fixing this! See the incredibly detailed workarounds and discussion on this ticket for why.
  7. Lee Morris 2017-03-09

    Closing ticket as the issue will not fix.

JSON Source