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
