It's straight forward to add a web page as a web application. Find here a nice article.
The issue know is keeping a session open. Once switching to another app the session is closed and the user needs to re-enter his credentials.
I've found a similar entry without answer in stack-overflow.
Some hints ?
Instead of storing the login info in a $_SESSION variable, store it in a $_COOKIE. The cookie will be saved depending on when you set it to expire. As long as they log in "inside" the web app, or the regular web version (and the cookie is the same) they will not have to log in every time or when switching between the two.
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);
I tested this to work on iOS 4.2.1, 5.1.1, 6.0 and 6.1. The session is even restored after turning off and restarting the device.
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
Related
we´ve been having problems with our iOS WebView app.
After our user logs in the app (on the web page), a Cookie is created and then WKWebView should automatically save it to device storage. (this is what I surmised so far, I don't normally develop iOS or WebView apps, so I'm sorry if I misunderstood some things).
This works, but if the app isn't regularly checked, the cookie will expire sooner than it's 60 day limit. (can't pinpoint one exact duration, but usually, according to our client, it's around two weeks).
Has anyone met or solved this problem before?
Thank you in advance for any tips/help.
Have a great day!
I have authorization in my app that happens through POST-request to the server. In response I receive json file and cookie.
I want prevent user to enter credentials every time. So the question is how to store cookies (session only cookie) between app launches. I concern here 3 cases:
User pressed "Home" and returned to the app before app was terminated by iOS
User pressed "Home" and returned to the app after app was terminated by iOS
User forced quit from app by swiping-out it from multitasking
It seems that i can use something like this:
NSHTTPCookieStorage.sharedHTTPCookieStorage().cookiesForURL(NSURL(string: "url")!)
But is it secure and will it persist in case 2 and case 3?
I've been working on similar iOS issues for the past few weeks.
Depending upon just how secure the credentials need to be, I'd suggest looking into using the browser's localStorage functionality to resolve this, rather than using cookies.
localStorage and sessionStorage are far easier to manipulate than cookies, and cross domain protections help avoid both user manipulation and 3rd party attempts.
If one was dealing with almost any other browser, one would generally use sessionStorage, since the values are preserved per log on session. But, iOS on mobile devices wil purge session storage far too frequently, rendering it useless.
The danger of using localStorage is that values persist between browser sessions. Where this becomes an issue is if a legit user logs in from a 3rd party device, the credentials are retained on that device unless the user has a way purging them (which is easy to accomplish using javascript).
The advantages of using sessionStorage and localStorage are:
1. ease of manipulation compared to cookies
2. no need to keep posting back cookies values to the server
3. less server overhead
note that on iOS in particular, if Private Browsing is enabled, both session and local storage are disabled.
I am using the HttpContext.Current.Session.IsNewSession to decide on what page to show when my MVC4 application launches.
This works great on desktop, iOS safari.
However on iOS Chrome, every time I close the browser (actually close tabs and close the application from the task manager) and relaunch it the IsNewSession is always false.
I am guessing it uses the session cookie ASP.NET_SessionId to track this as there is a new cookie value when I close my desktop or safari.
However on iOS Chrome, when I close and relaunch the cookie has the old value - which I am guessing is the root of the issue.
So why does iOS/Chrome not clear my ASP.NET_SessionId cookie even though it should be a Session cookie and deleted when the browser is closed.
Thanks.
I suspect this is because of a design feature of many modern mobile operating systems whereby apps don't really close when you might think.
With desktop applications you have a lot more screen real estate and so it's easier to manage windows and multitask. So closing applications feels natural and necessary when you're done with it.
With mobile applications, however, there is more of a focus on the user being able to open and switch between applications seemlessly and so the concept of closing or minimising apps is abstracted away and taken care of by the operating system.
This means that when you close Chrome, it's not really closing (and may not close at all before you enter the app again). Therefore the session is never cleared.
If you force close the app then your function will work as expected.
There's no elegant work-around that I can think of for your problem. One idea is to store the time of last activity for the user and if it's greater than, for example, 5 minutes, then you can show them your startup page.
I'm currently hard at work developing my first Web application, and I have stumbled hard upon an issue on the iOS mobile-devices' Safari Browser.
If I create a cookie set to expire in x days (basically any cookie created, session-only or otherwise), and hard-reset the browser on the phone (as in closing the app entirely or restarting the phone), the cookie is destroyed.
Why is that? And how can I avoid it?
The same thing happens with objects stored in LocalStorage.
Also, if it can not be avoided, what other way of storing my app-data should I use? Server-side storage is last resort here.
The phone settings have been checked, nothing indicates that the browser is rejecting- or is set to clear cookies on session/app exit.
As Shivan Raptor said, important data should be stored server-side.
After some fiddling, I also found that localStorage apparently survives app hard-reset, whereas cookies do not.
Closing.
The app I'm working on is used on an iPad in a retail display. The device has auto-lock turned off, and the app will show a video loop as a type of screensaver after a minute of inactivity. We are using the GA iOS SDK 2.0 beta to track sessions, with a session timeout of 60 seconds. The app starts a session on startup, and also when the screensaver is dismissed by a touch. This is all working fine except for the multiple 0-10 second long sessions we get, with average duration of 0:00. We can start the app, go through a couple of 60 sec. sessions, then get those sessions reported along with 2-3 of the 0-10 sec. sessions. From what I can see the app only starts sessions when it is supposed to, so I'm wondering if this is related to how Google calculates a session. I haven't seen anything in the documentation that explains this and I'm stumped.
Just found this answer from my friend
http://support.google.com/analytics/bin/answer.py?hl=en&answer=1144430&topic=1011345&ctx=topic
In my app I only have one view controller that uses [tracker trackView:#"my screen name"] and I have this stuck this in the AppDelegate.m for now as I hadn't got around to tracking views/screens yet. According to the linked material, the way GA calculates session duration is based on time between views. Since I only have one view defined (and not properly within the viewController), this may be the reason I'm getting so many 0-10sec sessions. Going to explore.
It might possible you are initiating a new session before tracking a event/pageview. Please Ensure that you are not starting new session everytime.
Refer this link
https://developers.google.com/analytics/devguides/collection/ios/v3/sessions