3 Replies Latest reply on Jul 10, 2015 9:14 AM by Jon Tara

    The hidden iOS gem in Rhodes 5.0.38 - shiny new network code!

    Jon Tara

      I was happy to find a hidden gem in Rhodes 5.0.38.

       

      Reading the release notes, one might think that 5.0.38 is all about per-app VPN (which is a really nice feature for BYOD Enterprise apps). But it's also the current official release, and it contains a hidden gem - two, actually, at least for iOS apps.

       

      There are two new settings in rhoconfig.txt. Here are the settings that I'm using, along with a small added comment of my own:

       

      # turn on http server traces, off by default
      # This is erroneously documented as effecting only 'local server traces' - not true
      # Update: as of 5.0.38 it appears this no longer traces external network operations
      # I think this just traces cUrl code. So, if ios_net_curl = false, this setting
      # has no effect. That makes sense - this will trace all cUrl networking, whether
      # local or remote.
      # Use this to get full trace on all HTTP requests OTHER than local server!
      # Note that the log level does not affect this setting - it is independent of log level
      # Note: this has no effect if using ios_direct_local_requests = true, becuase in that
      # case there aren't any "http server" network requests!
      net_trace = '1'
      # If true, an old libCURL-based Net request will be used.
      # This option can be enabled for regression testing or if custom proxy support is required.
      # Default is TRUE but, to support per-app VPN (ex. MobileIron) this option should be set to FALSE.
      ios_net_curl = false
      
      # If true, request to local server will be applied directly, bypassing socket intercommunication,
      # no network requests are involved. If false, a legacy client-server intercommunication will be made
      # for local requests. Default is FALSE but, to support per-app VPN (ex. MobileIron) this option
      # should be set to TRUE.
      #
      # Note: you will not be able to test pages by pointing a desktop browser to port 8080 if this
      # is set to true. I can't remember when I last did that, since we have Web Inspector.
      ios_direct_local_requests = true
      
      
      
      
      

       

      Read the true/false comments carefully, it's a bit confusing!

       

      Network code in iOS Rhodes has, up until now, been based on the cUrl library, and a rather old version of it to boot. I get the impression that it's fiddly and not something that RhoMobile has wanted to touch much, for fear of breaking it. Reading between the lines, it was probably easier to write some shiny new networking code, than it would have been to hack away at cUrl in order to include the per-app VPN capability.

       

      And reading through the repo checkin comments, I see encouraging things like "fixed multi-part file upload..."

       

      As well, up until now, Rhodes has exposed an IP port on which an HTTP server responds, and which handles requests from the WebView, as well as for queueing callbacks. That is normally a random IP port, but for some testing purposes, you can set it to a fixed port (typically port 8080) which allows you to point your desktop browser at it and facilities some easy testing of your pages.

       

      I'd imagine that those developers who want to use a per-app VPN are probably doing it because they are security-conscious (duh!) and wouldn't be too happy about exposing the HTTP server on any IP port - whether fixed or random. (It only takes a few seconds to scan all possible IPV4 ports on a socket to find an HTTP server.)

       

      So, now you have the option of not using an IP port at all for the local server. If ios_direct_local_requests is set true, no IP port is used, and internal communication is done without using or needing an IP port. This removes a vulnerability. I'd imagine there might be a technical implementation reason for this change, as well. (As in, if you use the VPN, I'd imagine ALL IP traffic goes through the VPN. And the Rhodes internal server is not at the other end of your VPN at the Home Office in Minneapolis...)

       

      You do lose the ability to view your pages from a desktop browser, but there is little to no need for that today, because Safari supports remote inspection/debug of WebViews in an app, and you can use it with Rhodes apps either in the Apple iOS simulator, or on a real device connected by USB. (Not available for production build, so, no vulnerability there.)

       

      The above settings are the ones I am now testing in a very large app that doesn't a great deal of network I/O to a variety of hosts (multiple APIs, Dropbox, etc.), and I have yet to encounter any issues.

       

      Tread carefully, as this is new. I'd love to hear about other's experience with these new hidden gems!

       

      I haven't looked at the other platforms - Android, WM, etc. to see what side-effects or benefits might be lurking in those platforms, or whether they've needed this much of a rewrite.

        • Re: The hidden iOS gem in Rhodes 5.0.38 - shiny new network code!
          Jon Tara

          There is on caveat I discovered with the shiny-new network code.

           

          The legacy network code is tolerant of invalid URLs. The new network code is not.

           

          I had a URL that had an un-encoded space character in it. The legacy network code apparently encodes this. The new code does not.

           

          I changed the space to %20. Of course, if you are going to routinely use URLs that need to be encoded, you probably should call an encoding method instead of using a literal %20 (or encoding of whatever other invalid character.)

            • Re: The hidden iOS gem in Rhodes 5.0.38 - shiny new network code!
              Jon Tara

              I also discovered that the new networking code leaves some additional "spam" in the iOS system log. I say additional, because a number of the new commonAPI modules do some logging that cannot be controlled through Rho::Log settings.  This applies only to iOS, and only in modules that use some Objective-C native code and log from that code.

               

              Setting ios_direct_local_requests to 'true' will generate log messages with each navigation that cannot be turned off.

               

              The bad news is this leaks URLs within your code to the log.

               

              The good new is that with this setting 'true' they aren't real URLs, (that is, the server is not really listening on a port) and it isn't possible to navigate to them from an outside browser.

               

              I've filed an Issue about the general problem of "log spam" in the new iOS common-API modules:

               

              NSLog system log "spam" in iOS commonAPI code · Issue #643 · rhomobile/rhodes · GitHub

               

              Still quite happy with the new network code in 5.0.38, I'd encourage experimentation!

            • Re: The hidden iOS gem in Rhodes 5.0.38 - shiny new network code!
              Jon Tara

              Looks like the new networking code is Not Ready for Prime Time on Android. I suppose this might be the reason it is not enabled by default.

               

              I've been using it successfully with 5.0.38 on a large iOS app, with no network-related problems. The app does a LOT of I/O with DropBox. Although I have not done formal tests, it seems faster.

               

              On another project, which uses RhoConnect, I also use it successfully with 5.1.1 on iOS. However, on Android RhoConnect fails login. I haven't investigated it further - the old "legacy" network code works as expected on Android.

               

              Interested in what others have experienced, and about other platforms, particularly Windows Phone.