Month: November 2015

iOS 9 and Ionic Side Menus

I encountered an issue with Ionic side menus where a previous view would partially obscure the current view. I updated everything, checked all my JS and HTML templates, verified links and state transitions, all to no avail.

I was stuck for quite a while until I finally decided that it’s probably an iOS-specific issue. A search then led me to this Ionic blog entry from 2 months(!) ago: http://blog.ionic.io/ios-9-potential-breaking-change/. I downloaded and applied the patch and that was it.

The issue is caused by an iOS 9 bug that affects AngularJS and thus Ionic. It’s supposedly “isolated to intermittent UI/navigation issues on some apps”. And, of course, I was one of the lucky ones. I can’t believe it hasn’t been fixed yet!

Bolinao

We along with James decided to go on a midweek trip to Bolinao to take advantage of the APEC holidays. Of course, it had to be up north because the south is gridlocked also because of APEC activities.

We decided to use Google Maps and Waze to guide us. I had deleted Waze a few months ago because of its tendency to lead me off the road (literally and figuratively) but James is still using it. Of course, both apps then proceeded to direct us to all the wrong places (as usual). We reached Bolinao a bit later than expected and it was almost lunch.

We checked out Puerto del Sol first. The tide was low and we were informed by the staff that it is rather low this time of the year. Optimistic, and having no real choice since we’re there already, we decided to push further on, bypassing resorts that had brown low-tide shores. Eventually we reached Treasures of Bolinao where we decided to have lunch. While there, we saw that the beach adjacent the resort was pretty good even at low tide.

After lunch we checked out the remaining resorts. GResort, which is well-recommended was unfortunately fully-booked. We checked out other beach resort (mostly basic huts and/or camping areas) until we stumbled upon La Parola who offered us a “transient” (essentially a house with kitchen) for the price of a room (P2500).  Since it was right beside Treasures of Bolinao and right smack at the pretty good beach we saw earlier, we decided to take it.

It was already siesta time and we were all tired from the long trip so everyone took a nap. Once we woke up, we immediately dressed up (down?) and went to the beach. The sand was soft, a bit coarse but not a problem. The water was clean and cool. And the sunset, the sunset was awesome!

There was no restaurant so we had to drive a short distance to the nearest “restaurant” for dinner. It’s actually walkable but it was dark and unfamiliar plus we had kids. The restaurant is basically just a small shed with a few tables (4?). But prices are reasonable and the food is what I’d call authentic. They don’t sell drink buts there are nearby stores that do.

After dinner, we went back and checked out the beach for anything interesting. Nothing aside from a few people drinking. Even the torches set up along the beach were not lit. We went back to our accommodations and very quickly slept.

The next morning, it was back to the beach for a quick dip before breakfast (at the same restaurant the night before) and departure.

We dropped by other sights along the way:

  • The Bolinao lighthouse which sits on top of a hill that offers a wide view of the coast. The lighthouse itself doesn’t seem to be operational.
  • The Enchanted Cave which charges P150 for entry. We didn’t take go in since we weren’t planning to swim inside the cave anyway
  • Bolinao church which is a Spanish-era church at the town proper
  • Maxine by the Sea where we had lunch. It is also by the Alaminos wharf which is the jump-off point for trips to the islands. The restaurant has a good, albeit far, view of the Hundred Islands where we had lunch. Food was fine but a bit expensive.

We didn’t go to Bolinao Falls anymore as it was a bit out of the way.

We got home almost midnight, tired but happy with the short adventure.

 

 

 

iOS 9 and the Firebase REST API

I was playing around with the Firebase REST APIs when I encountered the following SSL error:

NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL...

After some research, I found out that iOS 9 enforces App Transport Security or ATS which, according to Apple, “enforces best practices in the secure connections between an app and its back end”.

But I am using secure connections! After further research I found out that problem with the Firebase servers, specifically the SSL ciphers they allow.

By default, apps use only a specific set of ciphers for SSL communications:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Setting the NSAppTransportSecurity option will include the following ciphers, which the Firebase servers do allow:

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA

Setting the NSAppTransportSecurity option entails adding the following into the app’s Info.plist:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>firebaseio.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
            <false/>
        </dict>
    </dict>
</dict>

DHE stands for Diffie-Hellman Exchange. ECDHE stands for Elliptic-Curve Diffie Hellman Exchange. They both offer forward secrecy but ECDHE is just faster. So the NSThirdPartyExceptionRequiresForwardSecrecy is a bit of a misnomer.

Now I wonder why Firebase doesn’t just add support for ECDHE?

More at StackOverflow.