Databases
StackOverflow2013
Postsdbo
POAuthentication for a Cookie, or RESTful Key?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POAuthentication for a Cookie, or RESTful Key?
    primarykey
    data
    text
    <p>I've been spending a good amount of time researching how to best implement user authentication from an Android application to a Rails web server. I'm aware that there are engines available to take care of authentication on the Rails side for me, but what I need isn't very complex, and so I think I'm best off writing my own authentication code.</p> <p>I'm very interested in RESTful web services: in a stateless web server, code is much more readable, maintainable, and changeable to name a few advantages. As a college student working independently on this implementation, these things are not extremely essential to me, but I believe that a REST guided implementation would be ideal from a coding standpoint nonetheless. </p> <p>Because my application requires user accounts that maintain their own contexts, users will have to be authenticated when making requests to the webserver. If I were to implement this application in an entirely RESTful manner, I would not maintain sessions of any sort, and instead require that the Android application (client side) pass the current user's credentials (likely a single, unique key returned to the Android application from the web server on first login) on every request. This would be a valid approach, but I'm worried about the computational overhead that this might generate on the server side.</p> <p>Here's why:</p> <ul> <li><p>Looking up a user by a long string on every request in order to act on that user is going to be slower than having the integer user ID for the associated table row in a CookieStore session.</p></li> <li><p>I probably wouldn't be storing the RESTful authentication <em>key</em> in plain text in the database. I would probably use BCrypt and store the salt and hash for the key instead. Which of course leads to the computational overhead that this bullet addresses: using BCrypt to hash the received key on each request to test against the hash stored in the database.</p></li> </ul> <p>When I eventually require hosting for the production server, I really can't afford to be paying for a beast, just so that I can sport a REST badge. </p> <p>Assuming that the typical user makes 10-30 requests/day, and the number of users depends on the popularity of the app (which I cannot predict, but for the sake of this question, assume to be average), is it feasible to implement authentication RESTfully in my specific case? In other words, is the computational overhead that it might create going to increase hardware requirements for the server substantially?</p> <p>Thanks</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USksonic1055
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POAuthentication for a Cookie, or RESTful Key?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POAuthentication for a Cookie, or RESTful Key?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POAuthentication for a Cookie, or RESTful Key?
      1. USBen Woodall
      1. VTFavorite
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload