I'm having some weird problems with NSHTTPCookieStorage in my iPhone app. When I invoke the login action on my web service, the service sends back an auth cookie named "auth" as well as some other cookies.
When I log the user out, I call a logout action on the server which removes the cookies. If I print the result of [NSHTTPCookieStorage cookies] before calling logout, I see the auth cookie as expected. After I log out, I see that the auth cookie is no longer there (as expected).
However, if I close the application and restart it, the auth cookie is back!
I'm not sure what's going on here. It would be one thing if NSHTTPCookieStorage simply didn't persist any cookies, but it appears to be saving some of them.
Does anyone know what's happening? Do I need to manage cookies manually? Is there some way to commit what's in NSHTTPCookieStorage to disk?
There are three local storage mechanisms related URL requests that have an effect to how authentication challenges are handled: (obviously) NSHTTPCookieStorage, NSURLCredentialStorage and NSURLCache. NSURLCredentialStorage is probably the next place you should be looking at, but clearing all the caches is generally considered the surest way to have the effect that you want.
This snippet is handy: https://gist.github.com/559071 (clears all the caches).
Nick, I am assuming you are building on the IOS 4.x SDK with XCode 3.x. This may be a long shot, but you mentioned that you close the application and then start it back up again. As of IOS 4.x, multi-tasking is enabled by default on iPhone Apps. That means that whether you want it or not, your app will stay in memory if you simply close it as normal. The way to defeat this is go into your app-name-Info.plist and add the "Application does not run in the background" key to the list. Then place a check in the checkbox. I would recommend that you do a full clean and build at this point after saving your project. Also, would recommend that if you are running in the simulator that you completely reset the simulator by choosing "iPhone Simulator" and then "Reset Content and Settings" from the application drop-down menu.
I also faced the same problem and I solved it by using NSUserDefaults.
Please refer to this link.
Related
NSHTTPCookieStorage *storage = [NSHTTPCookieStorage sharedCookieStorageForGroupContainerIdentifier:identifier]; Not working between Extensions and core app
Has Anyone been using App groups and the shared Cookie Storage to handle all the cookies between the App, Extensions, or watch. I am saving all of my cookies to this shared cookie storage but when I open an extension and check the cookies they are not there. I have set urlsession and everywhere possible to use this cookie storage but they are not persisting outside of the main ios app. I have made sure app groups are set up correctly and the identifier is the same. I have logged the cookies when exiting the app, it says they are there but logging them when opening extensions shows they are for the extensions.
Has anyone had a similar experience?
Thanks for any help!
The problem was with the actual cookies themseleves. It seems the storage was only storing the non session cookies(ones with expiration dates) to the cookies.binarycookies file. The rest were just in memory on the app and not getting carried over. I added exp dates to the cookies and manually delete those ones later on
I've been doing a bit of research on the subject, and I'm a little confused about storing cookies within an iOS app. I want to be able to store a user's login credentials so that they don't have to log in every time they launch the app (much like Facebook's app does). I'm kind of lost on how to do that though. Here are some of the specific questions I have:
When the user logs in, does a cookie get stored automatically? If so, where? If not, how do I store it?
How can I check for that cookie and access it, examine it, etc.? Maybe on a relaunch of the app or something.
How is storing a cookie with user credentials different than storing them in the keychain? Or are they the same thing?
When a user presses "logout" in the app, should that delete the persistent cookie? It must, right?
What's the best way to store these cookies? What does iOS automatically do for you, and what do you have to do yourself?
Is there an advantage to using ASIHTTP stuff for things like this? If so, what does the ASI library offer that the NSURL stuff doesn't? Does the treatment of cookies change when using the ASIHTTP library?
As I'm sure you can tell, I'm pretty lost, and don't know all that much about how cookies work, but I'm trying to figure it out, and any help is much appreciated!
Are you using a webview for your app or something?
Update:
You should store the username/password combination in the keychain. There are several wrappers available for this, one of my favorites:
Keychain Swift
It is however; more secure to use an access token so that the username and password combination are never stored on device.
Are iPhone cookies enabled by default when you buy an iPhone? I ask as I do not want to build any features for a webapp which require cookies if most users do not have have them enabled.
Cookies are enabled for visited websites by default. In the settings app you can change the setting for cookies. What visited websites means is this (i think):
For example you buy a new phone or restore and visit youtube.com which is from google. google.com would maybe try to save any cookies to save your username and password ir anything but can't, because you have not visited google.com before. Only youtube.com will be able to save cookies on your phone.
Note there appears to be a bug in which this setting randomly changes to "Never". I don't know what the trigger is; some people are claiming it happens when updating to iOS 5 but I think that's just a coincidence of timing for certain folks.
I just had this happen to me when I restored my phone from a backup; however the backup was only an hour or so old and it definitely wasn't set to "Never" in the backup. I've been on iOS 5 ever since it released, and the cookie setting was definitely the normal default (1st part cookies only) until I did the restore last week.
Right now I am developing a Web-based Application, where the User has to login first.
When I open the Page by iPhone Safari, login and restart Safari, I am still logged in (Cookie & Session ID still set).
But when I add this Page with "Add to Home Screen", each Time i click the Icon for that page, I have to login again.
I did not find any information about that. What can I do so my users can set this page to their home screen
as icon and still don't have to login each time they open it?
A really simple approach could be to use a unique token in your Bookmark-URL which can serve you as a unique device identifier.
Example:
http://myWebApp.com/?token=randomId29238/1
The token can be generated at the server side at opening time of the application in Mobile Safari and before the user is prompted with the "Add to Home Screen" information.
The token can then be added to the URL using a quick redirect (…&token=randomToken) or a location hash (…#randomToken).
Whenever the Bookmark is now opened from the Home Screen, the token is sent to your server and you can identify the user's active session.
You may also use the token as a permanent session id, but I advise against that because of security concerns.
To allow future logout and login procedures, you can always assign the new sessions to the token.
The token will serve you as a unique device identifier whenever the user will re-open your link from his Home Screen.
There is an easier and, imo, more elegant solution than favo's.
At least under iOS 4.2.1, 5.1.1, 6.0 and 6.1 (I couldn't test other versions), if you extend the lifetime of your session cookie manually, Safari will hold on to the session cookie and even allow sharing of the session between the 'home screen installed' version of your web app and normal visits through Safari itself.
The trick is to do this:
// Start or resume session
session_start();
// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);
For a more elaborate discussion of this strategy you can take a look at my answer of this question:
Maintain PHP Session in web app on iPhone
I am going to expand a little further on Waldo Baggins' answer.
When I ran into this, I discovered the reason this was happening is that session cookies set on the server usually do not have an expiration value set. The default behavior in this case is for the browser to discard the cookie when the browser is closed / re-opened. Since the browser does not resend the cookie on re-opening, the server has no way of identifying the session, even if it hasn't expired on the server yet, and thus, your user is redirected back to the login page.
When the user is using your site in web app mode (icon added to home screen), iOS treats navigating to / from the app the same way a desktop computer would treat closing and reopening the browser, and loses the session when reopened.
So following Wilbo's suggestion and setting an expiration time for the cookie, iOS checks if the cookie has expired when the user navigates back to your app, and if it hasn't, re-sends the cookie, thus maintaining the session. The value of 1 year in Wilbo's answer is ridiculously long, you would typically want to set this to something like 8 or 24 hours, and ideally sync it with the session expiry timeout value you have set on the server.
Note that as a side effect, when your site is accessed from a desktop browser, and the user closes and re-opens the browser, the session would continue to persist and the user will still be logged in, which wouldn't have been the case previously (unless they were browsing privately). Your "Logout" feature would have to properly handle expiring this cookie.
For a Java webapp using web.xml version 3.0 or higher, the easiest way to do this is to modify <session-config> as follows:
<session-config>
<session-timeout>600</session-timeout> <!-- In minutes -->
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
<max-age>36000</max-age> <!-- In seconds -->
</cookie-config>
</session-config>
There are persistent key-value storage and database storage available for web apps. You can save your authentication data using localStorage object and use XMLHttpRequest to send it to the server.
Another option is saving your persistent data in a SQLite database, however this doesn’t seem to be a proper solution in your case.
Check out Apple’s Client-Side Storage and Offline Applications Programming Guide for details/examples.
So I was just curious if the NSHTTPCookieStorage was persistent across applications, or local only to the current one. I want some cookies gathered in another app to be accessible in a search app. Is that how it works? Thanks!
PS: This is on the iPhone or iPad.
For iOS, cookies are not shared across apps. Per Apple's documentation,
iOS Note: Cookies are not shared among applications in iOS.
Created a workaround where I just pass the credentials to the new app and reconnect to server. Not very efficient, but passable until something better is found...
As Greg said, No. Each apps cookie storage is sandboxed.
A solution to the problem would be to use a SFSafariViewController, new to iOS9.
This implementation of WebViews are not sandboxed and have access to Safari's cookie storage. Meaning that two different apps could use this to both access the same cookies from Safari's cookie storage.
You would need to write a small web-service to handle writing the cookies and some sort of API to redirect cookie data back into the app.
Use this project as a starting point. It shows you how you can access Safari cookies from an app without the user having to do anything.
Hope this helps,
Liam