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.
Related
I'm currently working on a PWA and noticed that the overall experience would be awesome for the users, if they do not have to sign-in every time they open the app.
I've noticed that on native mobile apps, the user stays signed in unless they decide logging out of the app.
I could think about the following approaches -
Make the session time super long; say 30 days or 180 days. I'm not aware of the downsides of this approach.
Create a cookie that says that auto-login link and use it to authenticate the user automatically when they open the app.
But there could be a way better approach than this; and I'm curious to know about it. Can someone help?
Well depends on your current user session algorithm, websites like facebook keeps me logged in for years, you might want to use
Local storage (Indexed DB) to store the user's data only update them asynchronously ,
Cookies, set a (x months) cookie and validate the cookie if it exist probably with the user's data,
This would be preferably done with your server side language and not client side.
Good day!
On one of our apps list of URLs allowed as redirects from FB login has mysteriously changed. I don't believe in wonders so probably someone has changed them. This change has caused several damages and currently we are discussing blame and damage cover as well as prevention of future incidents with our customer.
Question: can I see somehow who and when changed FB app settings or ask someone in FB support about that? There are many people having admin access to app and without tracking their actions undesired changes will happen again sooner or later.
Thank you in advance
Retroactively, you probably can't.
But you can set your app up to send a notification about any changes that occur, and by whom their are made.
https://developers.facebook.com/docs/apps/security#app-settings-security
Update Notification
In the event that such a takeover does take place, we have built a notification system to expedite discovery and recovery from such takeovers. This notifies relevant individuals when any app settings are changed using the App Dashboard. The notification contains information about what change was made and by whom.
An app can register an email address to which these notifications should be sent in the Advanced tab of app settings.
I am not sure if anyone has ran into the problem but it is really bugging me and affecting our uploading from our iPad to facebook.
I have a local server running XAMMP with a gallery of images displayed via a local web page. These images are from our Photobooths and automatically get added into the gallery when a photo is taken in the booth.
These can then be accessed on the local network via the iPad. Users can then login to facebook and share this images.
Because this is a shared iPad being used by multiple users, is there any way of getting users to login without having to answer security questions?? It used to be fine but now Facebook says the login is suspicious as it does to recognise the device.
I have created an App to post the photos to facebook through the Facebook Development site and it works perfectly from my account and many users, but some seem to get the suspicious login attempt and have to identify friends and date of birth etc.
Is there a correct way to do this?
Thank you Richard.
Is there a correct way to do this?
What you are experiencing is the “correct” way.
Facebook offers this as a security feature – a user can add his devices to his list of “known” devices, from which he will be able to login straight away, and have to answer additional security questions when logging in from a different, “unknown” device.
If users have this feature enabled, they should not be surprised by this happening in your scneario. It’s what they explicitly want, and they’re getting it.
So you should in no way try to mess with that, just because you might think this to be “uncool” or a “nuisance” – it’s not, it’s a feature offering extended security that the user wants and has explicitly chosen.
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.
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.