StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You're absolutely correct that most samples don't address security at all. And as a result I don't have a great sample that I can point you to. I can only tell you how we structured our own stuff:</p> <ol> <li><p>Like you suggested, we make an API call to authenticate the user. In our case there was a session ID created by the Java server as soon as the user hit the first page (even prior to logging in) and stored in a cookie client side. Since that cookie travels up with every HTTPS request to the server (even the AJAX calls to get data or perform commands) it is associated with a particular account server side once the user has authenticated.</p></li> <li><p>Assuming that your transport to the server is HTTPS and the cookie never travels over the open Internet, nobody can eavesdrop on that value and pretend to be that logged in user.</p></li> <li><p>In our case the server is Java based and a servlet filter sits in front of all of the API functions which are not publicly accessible (that is, the ones that require login). It checks the session and makes sure it represents a logged in user before passing on the request to the service and that keeps the service code clean of authentication checks. Authorization code and parameter validation however does currently sit in the service layer.</p></li> <li><p>AJAX calls to the API could fail to authenticate even when you do have a cookie accompanying them for a variety of reasons (the session has expired, the server had to be restarted and has forgotten the user's session, the admin forceably logged out the user, etc.). In our opinion, it's important that the server still return something (that is, not a empty response) and it shouldn't be something like a redirect to a login page (which is useless to an AJAX request). So we always return <a href="http://labs.omniti.com/labs/jsend">JSend protocol</a> responses from all of our functions and if the user isn't logged in, then the servlet filter returns a standard JSend "error" response with a particular code. That allowed us to have our client side code (which you could put into a custom Sync) notice that the user isn't logged in and prompt for a login. It's even possible you could automatically retry the function after they login but that's more sophisticated than we got.</p></li> <li><p>By having the Sync notice that the user isn't logged in or got a security violation you don't have to put anything special into the views. They just make whatever request they think is appropriate and it either succeeds or it doesn't. If a fresh login is needed, that gets triggered at a lower level.</p></li> <li><p>Logging out does not actually require you to kill the local cookie as long as the server marks that given session as no longer logged in or discards the session record.</p></li> </ol> <p>I disagree somewhat with Derick's statement that the client shouldn't know about security. I think it needs to know when to prompt for login, how to tell the server when to execute a logout, and I always think it's a good idea to have additional checks client side to avoid the principle of surprise. For example, I would prefer that the client suppress showing admin functions to me if I can't use them rather than allow me to try to invoke them and then get an error in response. </p> <p>Ultimately the server absolutely must check the user's permissions again with each request (because it's so easy to sidestep client-side security), but good UX requires that the client know that I'm not an admin so it can present the best representation of the UI for me.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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