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
