David, I'm developing iOS enterprise apps, and Big Dog is right, this is standard fare. I haven't had a single app where I DIDN'T have to do that! I don't know who your boss is talking to, but what he's being told is just dead wrong. Soapbox time.
It's not even that hard. Save the session data, try using that data in the http-header, and if it fails, get a fresh set of session data and retry. Yes, that involves -- um -- work. Expertise. When a standard API is available, I'm a happy camper, because I know that API is supported. The only time I ever had an issue was when someone wanted the app to do three levels of VPN tunneling and such for credentials to get to a hidden API (not kidding, I can't make that up). We said no, just give us one secure API entry with one auth, please. And we got that. We handled the session reauth, no problem. Everybody's happy. If this is a problem for your mobile guys (and I'm using that term very loosely right now), I have to seriously question their experience. I would never in my wildest dreams ask someone to have sessions that never time out. Let's hope the app tokens aren't being sent in the clear. Their suggestions are just plain crazy. So why? I have a guess. Perhaps they are developing in one of those cross-platform tools rather than native, in order to do iOS and Android with one code source. Ask Facebook how that worked out for them. If so, there's a good possibility they are masking a shortcoming of their development choice. Anyone doing native knows this can be done -- easily. If they can't handle sessions, they can't run with the big dogs. ;) They don't know how to do a serious app. They should go back to simpler apps, like loading web pages, or doing something with birds in it. I'd fire them on the spot. -- Cole Quoting Timothy Humphrey <[email protected]>: > And that's why we call him the Big Dog. Bam! > > -Timothy > > > > On Mar 25, 2014, at 5:03 PM, Ray Hunter wrote: > >> David, >> >> You are correct in that you should not be changing anything on your >> end. They >> should have their app server handle the session expired from your system and >> send that back to the device. >> >> The device should handle this properly and authenticate again to get a new >> session created. I am not sure why they keep pushing the blame back to you. >> >> Let me know if you have any specific questions. I am working with >> Android and >> iOS and we are creating apps like this all the time - using oauth and basic >> authentication that utilize tokens. This is all very standard. >> >> Thanks, >> Ray >> >> >> On 3/25/14, 3:55 PM, David Skinner wrote: >>> Hey everyone, >>> >>> We have a platform written in PHP. Our company has outsourced development >>> of a mobile app. >>> >>> When a user uses the mobile app, they have to log in with an existing >>> account. The app sends the login request to this other companies servers, >>> which then forwards the request to our servers where the authentication >>> happens. >>> >>> If successful, a session is created for that user on our system, and the >>> session information is passed back to the other companies servers and then >>> to the app. The user then can use the app. >>> >>> When the request comes from this companies servers, they use a unique entry >>> point that is specific to them, so our system knows it's for the app. >>> >>> The issue here is related to sessions. Our normal web sessions expire after >>> about 2.5 hours. The sessions we create for this app are the same. If the >>> user stops using the app, while leaving it running in the background of >>> their device, then after 2.5 hours, attempts to use some feature on the >>> app, it bugs out. >>> >>> Their app sends the request to the app's server, then to our system. Since >>> the session is expired for that user, we respond with a status that they >>> have been logged out. Their system doesn't handle that response, so the app >>> just stops working. The user then has to completely kill the app on the >>> phone and run it again to get the login screen. >>> >>> The company that makes the app has asked us to increase the sessions to >>> never expire. >>> >>> I don't agree with that solution. >>> >>> I temporarily increased the sessions ONLY for traffic from this app to 24 >>> hours. But the issue still exists. >>> >>> A solution provided by the app company is to have us pass to their system a >>> special token once a user has authenticated. They could then use this token >>> to either renew or start a new session once it expires. >>> >>> We have an actual API that this company is not using. I don't know the >>> reasons exactly. But if they used our API, the authentication would be tied >>> to their api key, not each user using the app. (Although they could still >>> verify that user credentials are valid). >>> >>> This company keeps convincing my boss that the problem is on our end. Maybe >>> it is, but it seems like the app should...work better. Shouldn't the app >>> know how to handle the response that the session has expired and they need >>> to log back in? >>> >>> Standing on my soap box here, I feel that we are being directed by them to >>> change our system to make this little app work, where it seems it should be >>> the other way around. They are our client. We are paying them. Why can't >>> they use our API? Should they change their system to handle our system >>> responses better? Especially ones that state the session is expired? At one >>> point they literally responded via email that their app has "...no way to >>> have the user go to the login screen in the app if the session expires". >>> >>> Surely changing our sessions to never expire can't be the right >>> solution...? Am I missing something here? >>> >>> Does anyone have any thoughts on this? >>> >>> Any comment is much appreciated. :) >>> >>> Thanks, >>> >>> David Skinner >>> >>> _______________________________________________ >>> >>> UPHPU mailing list >>> [email protected] >>> http://uphpu.org/mailman/listinfo/uphpu >>> IRC: #uphpu on irc.freenode.net >>> >> >> _______________________________________________ >> >> UPHPU mailing list >> [email protected] >> http://uphpu.org/mailman/listinfo/uphpu >> IRC: #uphpu on irc.freenode.net > > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net > _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
