I have a PacketTunnel Provider extension running with my app. Once a user un-installs the app I get a call "stopTunnel" with an identifiable reason.
Trying to send a last network request appears to fail. Yet I'm wondering if there might be any low level network options I should try before giving up on this quest?
Happy for suggestions even if they are un-verified. I can try them in my set up.
Related
Is there any configuration like android user-permission in iOS to control access to internet?
I think all new projects access to internet by default, is that correct?
When I send a request to the internet it returns 0 http-error code, it means I can't access to the internet.
yes, it is correct all the new ios project have access to the internet by default.
A status code of 0 in an NSHTTPURLResponse object generally means there was no response and can occur for various reasons. The server will never return a status of 0 as this is not a valid HTTP status code.
Any http request will first be processed by the operating system, and during that phase you can get an error. Getting an error means that your request never got a response from the server (and with the exception of https requests where certificates were not accepted, most likely didn't reach the server).
If this phase succeeds, then you get eventually a reply from the server. This may take time, you may have to wait 60 seconds. Which is why you do all your internet requests on a background thread. That reply will have a status code (status, not error). The status code is NEVER 0.
By default, iOS doesn't allow http requests, and doesn't allow https requests to unsave servers, so you better use only https unless you have a very good reason. You will need a very good reason to convince Apple to let your app on the app store if you want http requests to succeed. But if you get this wrong, you get an error quite early on.
A status of zero most likely means that a background request didn't finish by the time you read the status, a basic programming mistake. You need to learn how background threads and callbacks work. Without that, you won't be able to use http successfully.
Also google for "Reachability" which can tell you if your app currently has internet access (like when WiFi and Mobile Data are turned off, or in Airplane mode).
We have an app that heavily relies on being able to access a user's session token using iOS's Keychain. When our app opens, the first thing that's checked is whether the token is available - and if not, we show the user a login screen. We do not use any 3rd party library for this, and use Keychain's SecItemAdd() / SecItemCopyMatching() directly with the following options:
kSecClassGenericPassword
kSecAttrAccessibleAlwaysThisDeviceOnly
We see little to no issues with this during normal usage.
The Problem
We've had users reporting that upon opening their app, they're shown the login screen (suggesting Keychain could not find a value), when they were in fact logged in. We found that in this instance, we found that upon killing and relaunching the app, users were back to normal (session was found in Keychain). Once we found this, we tried added an exponential backoff to keep querying Keychain, thinking that it may had only been unavailable for the first few seconds. This did not work, and proved to us that Keychain seems to be unavailable for the entire app launch session. We are not able to reproduce this issue. It seems to happen very intermittently.
Upon further investigation, we found that commonly, users had received VoIP Pushes prior to having this issue. We're still not able to reproduce this issue reliably, but upon debugging, found that our Keychain.session was found to be nil when receiving these pushes (we rely on it there as well), which is before the user would open their app to see that they are pseudo- "logged out."
We use PushKit and PKPushRegistry in order to do VoIP Push. This requires our app to have "Background Modes: Voice over IP" enabled. We use all of this as suggested by Apple's documentation. Here's a sample:
func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType) {
guard let _ = Keychain.session else {
print("Session token not available")
return
}
handle(notification: payload.dictionaryPayload)
}
This code relies on Keychain.session being immediately available upon receiving a VoIP Push. As mentioned before, we've seen instances where it is not available, and so this function logs out and simply returns.
I've also found this relevant Apple forum post, suggesting that this could be an iOS bug.
Can anyone help us with this issue? Any help would be greatly appreciated. Even if this is in fact an iOS bug, we're open to workarounds.
I think this topic is driving the iOS dev community literally crazy since long time. I've read so many articles and thread about this that I lost the count.
So, I'm dealing with this issue too, and based on the #naqi answer, I started moving in that direction and I might have found a working solution.
Assumptions:
The issue seems to happen when the app is getting suspended, due any sort of reason (eg. the app in background from long time and due memory pressure the OS send it in suspended state, or the app is in bg and user upgrades to a new version from the store or automatic app update does it). I'm no longer fully sure what suspended means, but I strongly suspect that the app may get resumed/awaken without actually getting presented on the screen (due bg task, but not necessarily).
One Apple stuff member on the Apple developer forum, had the brave to reply saying something like "try to put a delay between addDidFinishLaunchingWithOptions and appDidBecomeActive". Apart from the madness here, reading that comment made me consider that maybe when the app gets resumed it triggers the addDidFinishLaunchingWithOptions but of course not the appDidBecomeActive (as it may not be resumed by the user but from any sort of event handled by the OS in background, for which we may not have the control seems, or any other feature like bg task or silent push notifications etc).
Extra info:
According with a quite old penetration test article I've found on the web (https://resources.infosecinstitute.com/iphone-penetration-testing-3/) querying the keychain actually would address the query to another process called securityd running on the device, which magically schedule the queries and performs them to the keychain db and, finally returns back the content to the requesting app, assuming that the app is still alive when the query gets completed on the keychain db. This made me think that, if that is still true, such process may fall in sort of "DDoS" attack where your app (or maybe all the apps in execution? Not clear how it actually works) performs too many queries. This may lead to false positive errors like secItemNotFound or similar. Again, as nobody confirmed this, keep it as my personal consideration.
Approach:
From the #Naqi answer, I could exclude the points 2,3 and 4, keeping the point 1 as only still valid reason. Said that, I decided to move any CRUD operation dealing with the keychain, from the addDidFinishLaunchingWithOptions to appDidBecomeActive, by handling the app setup instructions (whatever needed by your app) in there, in order to make sure that eventual background events of suspending/resuming actions won't affect the keychain at all as the appDidBecomeActive would not get called unless user actually makes the app to get opened and shown on the screen. Of course this should happen only on app launch, so you can use a bool flag or similar semaphore approach in appDidBecomeActive to make sure your setup logic is executed only once.
Combined with the above approach, In the App Delegate I also explicitly implemented application(shouldSaveApplicationState:) by returning false and application(shouldRestoreApplicationState: still returning false (Even though I assume by default should be already like this). This may not necessarily be useful but it was worth it to try too.
Summarising, on some affected devices which were randomly failing the keychain access, seems now not to happen anymore since weeks and, consider this was happening for some, almost every 2/3 days let's say, I assume it might have attenuated the issue at least.
I can say that the monitored devices were all in different configurations, with a lot of apps installed or not, with storage memory almost full or not, with a lot of apps in bg or none at all, any form factor and different iOS versions. Keychain backup to cloud not enabled, and items attribute on the keychain at least as kSecAttrAccessibleWhenUnlockedThisDeviceOnly
Open point not fully verified: Supposedly the access to keychain should be thread safe, but I found different thread on the web contradicting each other. Maybe that could somehow impact your logic and cause unexpected state
(Congrats if you managed to read up to here :) )
Hope this helps to further understand what's going on with this keychain tragedy in iOS
I was having similar issues and after talking to engineers at WWDC we identified few issues that is leading to this behavior.
We were calling Keychain too often and this can lead to a situation where it gets expensive and some calls would not finish or timeout
If an app does not provide Access Group for keychain or does not add it in save transaction with keychain then Xcode generates one but this is dynamic and can change between dev environments
If you provided an access group later in the life of your app, then your old keychain value will remain associated with the app and a new value will be created with the access group you will now provided
This also means that when you query keychain you have to provide an access group otherwise you will get a reference to what ever was found first.
Edit: formatting
I'm writing an app using Parse which saves data to the server over a connection with unknown stability. As such I'm using saveEventually.
I'm trying to deal with the situation where the app is minimised, and then terminated by the system before a save is complete. The trouble is, when
opening the app afresh, I issue a logout command, since users are required to log in. It appears that this logout command can overtake the save commands, removing the session from the server, causing the queued save commands to fail. (I also can't see any way of handling these failures after an app restart, since I don't see any delegate based handlers, and blocks are cleared.)
I can't see any user-facing solutions to this either, since there is no guarantee when saveEventually might decide to run, and I can't block the user indefinitely.
Has anybody dealt with this? Any suggestions are most welcome.
I have an iOS app that uses a Nest Thermostat. Specifically, I want to set the Away/Home status, and then set a target temperature on it.
It works at first, but after some calls to the Nest API, i receive this error:
Error: Error Domain=com.firebase Code=9999 "{"error":"blocked","type":"https://developer.nest.com/documentation/cloud/error-messages#blocked","message":"blocked","instance":"cb7307d1-4fdc-4caf-9f80-f9ad57764dd8"}" UserInfo={NSLocalizedDescription={"error":"blocked","type":"https://developer.nest.com/documentation/cloud/error-messages#blocked","message":"blocked","instance":"cb7307d1-4fdc-4caf-9f80-f9ad57764dd8"}}
This happens both the simulator and the actual device.
I am based on the sample code provided in the Developers Nest website. It uses the Firebase API to connect to the NEST. I have seen this post with the same problem whilst authenticating, but I have this problem while trying to awake it. It takes around 20 minutes to be available again.
I also tried to call [Firebase goOffline] when I don't need to connect to it, and [Firebase goOnline] when I do, but it seems useless.
Do you know how it should be handled, and how to unblock the nest?
To sign in and access various functions of our iOS app, the user needs to be connected to our VPN network from their iOS devices. The webservices that the app calls are also only accessible over VPN. In order to determine if the user is running the app over VPN (online mode) or if the user is running the app outside of VPN (offline), we are using Apple's SimplePing class helper https://github.com/chrishulbert/SimplePingHelper. We pass the host name of our web services to make the ping call. If it succeeds, we conclude user is on VPN. If the ping fails, we conclude the user is not on VPN and give him a message saying he needs to connect to VPN.
The issue we are seeing is that sometimes we get a ping failure even if the user is on VPN and this results in the user getting a message that he lacks connectivity. If the user tries some action again, the call succeeds.
We are not sure of what causes the pings to fail intermittently and succeed again when tried in a few seconds. Has anyone experienced this kind of an issue? What could be the possible cause and resolution? Any ideas are welcome.
We use SimplePing and I noticed that sometimes it fails to resolve the hostname (in -(void)hostResolutionDone) even before it gets to the actual ping. I haven't yet figured out why but my workaround was to stop/restart the ping service. The host resolution failure happens infrequently so it usually corrects itself the second go around.