I have an angular.js single page app that authenticates against a RESTful API (Servicestack). This all works fine. When the response from the authentication api is returned the username is stored on an Angular service and an isAuthenticated flag is set to true.
Any requests against an [Authenticate] attributed web service then returns data.
My issue is that when I refresh the browser my javascript angular objects are flushed and the fact the user authenticated is forgotten. Yet when I call the [Authenticate] attributed service they work correctly because the session is still live...
Apologies for the rather noob question but how does the browser pass the session to the web service when the javascript objects have been destroyed and recreated? How do I grab the same session on refresh and set my Angular service up with the username etc.?
ServiceStack Authentication uses cookies to store the session token by default. Which means your Angular application will receive the cookie when you first sign in. It will pass this for subsequent requests, and they will succeed while the session is still valid on the server.
The problem will be that Angular will lose the object state, when you refresh the page, that is telling it you have an active session. So you must restore this knowledge to Angular. There are two ways to tackle this:
Check for the ss-id cookie when you application starts and assume you have a valid session. In other words, so restore to a signed in state, until you get a 401 error from the server. This is the quickest approach, and doesn't require additional overhead to check the session if somebody refreshes the page.
Check for the ss-id cookie and make a test authenticated request to check the session is still valid.
If you need to restore other information such as the current logged in user's name etc, then you would need to store that in a cookie/local storage to restore it on refresh, or go with method 2, and retrieve it back from the server.
You can use $cookies provider to manage the session cookie.
Related
I'm building an app and an API endpoint using PHP(I know what you thinking!). My issue is that if I ask user for username and password on opening the app for the first time, since I can't store these details locally because they could be compromised. I'd send these through Post request to server then generate a token depending on whether the user is the right one. After getting response I must store this token locally right?
Yes!. there's expiration for the token. After the token is expired, I don't want to ask user for their name and password but want to access API still authenticating as that user. How will I do this?
If I use Oauth it's still the same procedure right? I should store something locally. won't that be compromised? I'm very confused.
How does other apps work. I'm sure they doing something in the background. They ask us for credentials only once and all subsequent API calls will be secured. Won't the token expire in that case or what?
Can i secure API calls without storing anything locally? I don't want API to be accessed from anywhere else but app.
Use android SharedPreferences. It should be very secure unless you deliberately expose it e.g. its accessible via an exported content provider missing the (android:exported="false") in the manifest. You can also use sqlite but there is no point of using a db table for one or two rows of data.You can also encrypt the user name and password to add one more security layer to protect rooted users.
Furthermore to protect the data in the network you should use ssl in the backend so no one can sniff the credentials.
I'm trying to understand how most online websites authenticate and then store your session. What I'm particularly trying to understand is when I log into a website it starts off by redirecting me to the login page and then validates my username/password, then navigates back to where I started but with my information displayed. If I were to navigate away from that webpage and then come back to it sometime later I'm still logged in. I feel like this is what a cookie could be used for but I'm looking to see if anyone could provide me with a good explanation as to how this works?
A cookie is a bit of data stored by the browser and sent to the server with every request for instance a subscription status on a website.
A session is a collection of data stored on the server and associated with a given user (usually via a cookie containing an id code)
Session values are reset after the connection is closed. Cookies values are normally saved.
Session values are usually reset after a period of time has passed without a connection from the client with which the session is associated. Cookie values are saved until their expiry time (or the browser is closed if one isn't set). Expire immediately overrides are available for both
I have several web pages that should work only if certain condition is true. For example, there is a registration page, a login page. If someone is already logged in, I don't want the user to login again or register again until he is logged out. Currently the server saves the login in a SESSION variable and each web page has to called the server to get the SESSION variable and determine whether to display the page or not. This does not seem like a good solution. I am thinking may be saving in on the client side, but I don't know a good approach. Should I use cookie for this ? Is there some other services on the client side to store session data ?
Cookies are the best option for session details involving login, any other persistent storage should use localStorage.
This is because cookies will be transferred to the server on each request and therefore can be used to authenticate each call.
If your confused about this sort of stuff it can be very dangerous for your site. Try read up on it and try to use whatever the standard is for your language/framework/library.
I am building a REST API.
Client side, I use Backbone.
Upon authentication, the API sends a token via ajax over to Backbone's Session model.
I place that token using jQuery's ajaxPrefilter method, to be send back the token towards the API on every request.
Everything works perfect, until the users refreshes the page.
If the page is refreshed, the token is lost, the model re-initializes and the user has to authenticate again.
How can I bypass this?
1. Store the token inside a cookie (very unsafe, bad idea) - defeats the REST purpose.
2. Store the token inside LocalStorage - equally bad, I believe.
Is there something else that can be done?
Thank you!
You can store the token both ways.
If you're using ssl, the token is only available to the client (and NSA, maybe) which brings no problem.
I rather store those token using localStorage unless the client doesn't supports it.
You can also check this answer
Keep Session Across Page Reload In Backbone JS
When working on an Angular app, I have a single page app that communicates with a JSON web service for data.
A "login" in my Angular app is really just exchanging a username/password for a token. That token is passed as a header on all subsequent requests so the server can authorize them. This works great until the users refreshes their browser window of course (via refresh or leaving the "page" and returning).
Obviously one option would be to make the user enter their username/password again, but that seems like a good way to not have any users.
I can think of 4 options:
Store token in a secure session cookie. (What I'm doing now. I am only using so the client can read. Not used or wanted on the server.)
Store token using local storage of some kind. (Would be insecure and
require manual expiration maintenance.)
Prevent user from refreshing browser with some "onbeforeunload"
code. (I don't like when I get the "are you sure you want to leave
this page" messages and I assume others feel the same.)
Include token as part of url. (Could make url's look big and messy. Possible physical security risk. Might make for extra work with bookmarking and expired tokens.)
Is option 1 the best option for this functionality? Is there something better to do than all of these?
I think option 1 is the best one for your use case. All major web frameworks have support for this option.
In case you need to handle this manually you need to ensure these steps:
The web service will process the initial authentication request by creating and setting a secure authentication cookie. The auth cookie should be time based(only valid for a specific time interval) and its value should be a unique value if possible;
After the initial authentication request all subsequent requests will pass the authentication cookie with the request header automatically - this is handled by the browser.
The web service needs to handle cookie based authentication on subsequent requests by validating the cookie value and returning an error if the cookie has expired.
You need to ensure a client side global authentication handler captures any authentication exceptions and displays a friendly message to the user.