Search code examples
androidsecurityrestinteraction

Problems of security code of android app when interacting with Java RESTful services


I build a RESTful service using spring and maven, also, I wrote an Android app to access my website and there is a security code on login page of app.

Now, I can get the security code image from server and display it on login page successfully, but when I send the correct security code and account information to server, I found that I cannot find the security code which was saved when it is generated. I saved it to a session object as an attribute, but it turns out to be different session objects because downloading security code and login are two different requests. I need to validate the security code, so I hope someone would help me with following questions:

  1. As downloading security code and login are two different requests, how do server know whom a security code is generated for? Where should I save the generated security code in server side?
  2. For security code image, what I returned to mobile app is a byte array, and convert this array to image and then display it on Activity, how do you return this image to mobile side? Is there better ways?
  3. I want a session of a mobile user is valid from successful login to session time out, So I am wondering how to maintain a session of a mobile user?
  4. Besides RESTful services, usually through what ways an Android app can interact with server?

Sorry for my English, Hope I have described my problems clearly...

Any answer would be much appreciated, thanks in advance.


Solution

  • Sounds like you need to make some pretty high level decisions about how your services (and therefore your client) need to be architected.

    The first thing you need to decide is whether you want your services to be stateful or stateless. Traditionally, REST services are stateless, but these are your services, so that is your choice to make.

    1. As downloading security code and login are two different requests, how do server know whom a security code is generated for? Where should I save the generated security code in server side?

    If you are going the stateful route, use a session cookie. The service will begin the session when the request for the security code image is received from the client. the client will set the cookie when it receives the response from the service. That session cookie will map the client's subsequent requests to the session, allowing the server to associate the requests with the security code.

    If you are going the stateless route, you should pass another piece of info to the client, say some uuid. The client's next request will contain the security code and the uuid. The server will keep a mapping of uuid to security image, allowing it to verify the client's request.

    1. For security code image, what I returned to mobile app is a byte array, and convert this array to image and then display it on Activity, how do you return this image to mobile side? Is there better ways?

    Byte array is fine. Base64 encoded String will also work. You could potentially just include an http link to the image. Your call.

    1. I want a session of a mobile user is valid from successful login to session time out, So I am wondering how to maintain a session of a mobile user?

    If your services are stateful, you should use a session cookie. Your Android client should be able to keep a cookie store to hold the session cookie and send it for every request.

    If your services are stateless, and you don't want to send the username and password for each request, you will want some kind of temporary authentication token. The services will be in charge of expiring that token. The client will be in charge of saving state and passing all necessary info to the services for each request.

    1. Besides RESTful services, usually through what ways an Android app can interact with server?

    Android has is capable of HTTP out of the box, and there are a number of good third party libraries that will assist you with this if you need them. But Android can also drop down lower than HTTP if you so desire.

    Your question here is really vague. Sure, most networking is done over HTTP (using REST or whatever), but it does not have to be. That is up to you to decide what you want your services to support, and then make the client conform to it. You could use SOAP if you are feeling particularly masochistic. You can make up any contract you want.

    The reason why REST is a very common structure for web services is that it is intuitive to the HTTP specification and it is easy to implement on most types of clients among other reasons. ,