Design question

  • Thread starter Thread starter Anthony Papillion
  • Start date Start date
A

Anthony Papillion

So I'm developing a new application for Windows Mobile (WindowsPhone) that
will use a REST API I'm developing to interact with a backend MySQL server.
While I need to make access secure (it's a medical app), I don't want the
user to constantly have to hit the user table of the database every time
they want to do an API call as that table could have thousands of rows and
could slow down access a bit.

So my thought is to use sessionID's of sorts. When the user does the first
call to the API (which should be a login call since they need to login to
the app), the mobile app will also create and send a unique 22 digit number
that will serve as the session id (alternately, the API could return a
session ID but that's besides the point). The session ID will be stored on
both the server and client side along with the time it was created. The
session will be good for six hours after which the user will need to login
again and create a new sessionID.

Now, each time the mobile client hits the API, it will 1) check the
on-device database to see if the session has expired (look at the time it
was created and see if it's older than six hours). If the session is older
than six hours, go trough the login process, create a new sessionID then
execute whatever calls are needed and 2) make API calls that include the API
command along with any required variables and send along the sessionID with
the call.

This sounds very convoluted but it's the best I could come up with. Can
anyone point me to a better way?

Thanks!
Anthony
 
Anthony said:
So I'm developing a new application for Windows Mobile (WindowsPhone)
that will use a REST API I'm developing to interact with a backend MySQL
server. While I need to make access secure (it's a medical app), I don't
want the user to constantly have to hit the user table of the database
every time they want to do an API call as that table could have
thousands of rows and could slow down access a bit.

So my thought is to use sessionID's of sorts. When the user does the
first call to the API (which should be a login call since they need to
login to the app), the mobile app will also create and send a unique 22
digit number that will serve as the session id (alternately, the API
could return a session ID but that's besides the point). The session ID
will be stored on both the server and client side along with the time it
was created. The session will be good for six hours after which the user
will need to login again and create a new sessionID.

Now, each time the mobile client hits the API, it will 1) check the
on-device database to see if the session has expired (look at the time
it was created and see if it's older than six hours). If the session is
older than six hours, go trough the login process, create a new
sessionID then execute whatever calls are needed and 2) make API calls
that include the API command along with any required variables and send
along the sessionID with the call.

This sounds very convoluted but it's the best I could come up with. Can
anyone point me to a better way?

Thanks!
Anthony
Click to expand...

I believe that's basically the procedure that most would follow.

However, I hope you're using HTTPS/SLL to connect with the server - at
least during login, but probably for all communications (if the data is
sensitive).

And, if your mobile app is not a web application, then it just confuses
matters to use the term SessionID (which applies only to web apps) - the
data (eg GUID) produced by the server for authentication / authorization
purposes after successfully logging in is usually called a ticket.

I would also destroy the ticket (on the server) when the user logged out
- not just after 6 hours.

The ticket is also normally passed in the header of a HTML get/post and
not as a parameter to each function called.

I would also look into the possibility of using OpenRasta which is quite
a popular REST framework (though I haven't yet used it).

HTH
 
Back
Top