When Apple started to require TLS 1.2 I had issues with it and turned it off in the info.plist. Now that they are going to require that it not be turned off for apps in the app store, I'm revisiting it. I've found some Xamarin articles on it, such ashttps://developer.xamarin.com/guides/cross-platform/transport-layer-security/ andhttps://developer.xamarin.com/guides/ios/platform_features/introduction_to_ios9/ats/#ATS-Connection-Requirements but they are not dated and the information does not appear to match my testing. What I have found it, running against a TLS 1.2 secured server, everything just works - both webviews and API calls using System.Net.Http.HttpClient (HttpClientHandler) return what is expected without error, without any special configuration. Are the articles above outdated?
I am also getting unexpected results when running against a non-secured server. The webviews do return an error as expected, but the API calls return JSON objects with the expected data, no security error. Why isn't TLS 1.2 required for these connections?
Any help / clarification would be much appreciated!
Related
I am having a web-app (serverless) that I am using for a long time. The idea is that the app gets contacts from my Google Account, and then I can do some actions by using this data.
Unfortunately, last days I started to recieve CORS errors... I didn't pay attention, but today I tried to fix it. And I realized that all other Google APIs like maps, locations, OAuth work properly.
The only problematic one is the Google Contacts API. I wonder, it's possible to continue using this API on the client side? I didn't touch the code and google-cloud settings. This is a very strange behavior...
Failed to load https://www.google.com/m8/feeds/contacts/default/full?v=3.0&alt=json&access_token=......&updated-min=2018-08-09T22%3A00%3A21.000Z&max-results=500:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://.....' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
The issue is fixed on Google's side (was a bug).
I have an IOS App that sends HTTPS request to a server, using NSURLConnection, it works without any issue.
Now, I'm trying to put this App on OSX and to reuse code from the IOS App. It's the first time I'm developing on OSX, so I'm a beginner ;-)
My OSX get an exception when I'm sending my first HTTPS requests (using Post), the exception is about NSURLConnectionLoader (it ends at libc++abi.dylib __cxa throw and it seems it has been raised due to security issue Security::KeyChainCore...).
Next, on the debugger, if I click many times on continue, the request is successfully sent and I'm get the correct answer from the server.
The following requests that are sent are working fine (no exceptions), only the first one has issues.
Any idea? Any differences between OSX and IOS for NSURLConnection?
Thanks for the help,
Sebastien.
We have a need to consume an external REST Api and dynamically update content on our website and have ran into the age old problem of cross site scripting and Ajax.
I've read up on JSONP however I don't want to go down that route in a million years as it seems like really a rather dirty hack.
As a solution to this issue is it "right" and "proper" to have a local service that acts as a proxy for any requests to an external Api? So on the client there would be an Ajax call to ../RestProxy/MakeRequest passing it the details of the request it needs to make to the external api, it performs the request and returns anything passed back.
Any thoughts would be appreciated.
There are three ways to do this:
1. JSONP
This is accepted by many popular APIs and frameworks. JQuery makes it easy. I would recommend this.
2. Proxy
Works pretty much as you described. Adds an extra step and server code and server load for you. However, it does allow you to filter or otherwise manipulate the results before sending them to the client.
3. Rely Access-Control-Allow-Origin
This is a header that the server can set to allow you to read json directly from their server even though you aren't on the same domain. This eliminates the need for the jsonp hack, but it requires the the server be setup to support it and it requires a web browser that supports it.
Access-Control-Allow-Origin is supported in:
IE8+
Firefox 3.6+
Safari 4.0+
Chrome 6+
iOS Safari 3.2+
Android browser 2.1+
If you need to support IE7, then this option isn't for you.
I have been using Google Places API inside my application. The client code is written in Java. It was working fine till couple of weeks ago and suddenly it started throwing following exceptions while making API call:
javax.net.ssl.SSLException: hostname in certificate didn't match: <maps.googleapis.com/209.85.175.95> != <*.googleapis.com> OR <googleapis.com> OR <*.googleapis.com>
I am using following URL for making API call : https://maps.googleapis.com/maps/api/place/search/json?
Also tried with different Google API keys generated from Google API console.
Can someone please point what I am missing here?
Many thanks
I used the latest Google API (version 1.13.2) which support better SSL options:
ApacheHttpTransport.Builder transport = new ApacheHttpTransport.Builder().doNotValidateCertificate().build();
Building an app using a calendar on a Google Apps domain that has SSL enforced domain-wide. I initially found the problem when building a Rails app using the GCal4Ruby library, which used the allcalendars feed URL with a non-SSL protocol (GCal4Ruby debug output snippet [sic]):
…
url = http://www.google.com/calendar/feeds/default/allcalendars/full
Starting post
Header: AuthorizationGoogleLogin auth=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGData-Version2.1
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
Redirect recieved, resending get to https://www.google.com/calendar/feeds/default/allcalendars/full?gsessionid=xxxxxxxxxxxxxxxxxxxxxx
…
This was interesting because it seemed to continue forever. I think I've fixed this in GCal4Ruby locally by creating the ability to use the allcalendars feed with the HTTPS protocol (i.e: https://www.google.com/calendar/feeds/default/allcalendars/full).
The thing that worries me is that I see no mention of the allcalendars feed needing to specify the HTTPS protocol in the Google documentation. That, and the fact that when I access the same domain using the Zend GData library in PHP, it works fine accessing the non-SSL private feed (i.e. http://www.google.com/calendar/feeds/r-calendar.com_xxxxxxxxxxxxxxxxxxxxxxxxxxx%40group.calendar.google.com/private/full).
So, the question: What am I misunderstanding? Is it just the allcalendars feed that needs to be accessed with SSL and the rest of the private feeds can safely use the authentication token?
Anyone have any insight, or pointers to some good docs?
So, it looks like perhaps redirect to the normal URL is normal for authentication, but that the library is not handling the redirect correctly because of some differences between the way Google Apps and Accounts work on the backend. This is in contrast to the Zend library, which seems to handle this more robustly. That's my current guess, anyway.