I am writing a web app with Backbone.js and require.js that needs to store user information to use throughout the app when the user login. Currently, when the user submits there credentials a web service authenticates the user and returns data about that user. Traditionally I could then store that information in a session. How can I accomplish this using Backbone?
You might want to use HTML5 SessionStorage for that. Have a look at this SessionStorageAdpater for backbone integration.
Typically one stores authentication information in an encrypted cookie that is sent to the server on each request. This is essentially a value that correlates the logged in user to the web server's identity store.
You are probably more interested in profile data (i.e. metadata about the user - firstname, birthday, etc). Once the user has logged in, when the page loads, fetch the profile data about the current user via an ajax call to the server (the request would include the auth cookie, which the web framework would use to find the currently logged in user). So you should expose a route on your web app that returns a json data structure containing the profile data your app requires about the current user.
I am currently in the process of writing a large Backbone / Marionette application. I'm storing the user information (not password or another like that) in a model called user. I then use this model to first validate the user by checking the sessionid.
// before every request
if (app.Core.models.user.get('sessionid') != "") {
// then I run the code. Authentication can still fail on the server.
} else {
// trigger the event to bring up the sign in page
app.vent.trigger('App:Core:Login');
}
After the user logs into the application, I save the information I received from the authentication inside the app.Core.models.user model. Since my authentication does not return a full user name, I make a separate ajax call to retrieve this information and store that information in the model too. I then tie the model to a section of my page that automatically updates the user name in the header of the page.
The browser automatically stores an encrypted cookie so I don't have to send any of this information back to the server.
Related
I want your advice on the best practice for storing and reusing user data in my application.
I created two apps:
the first is an API to recover data
the second is a Vue.js application for the front-end part
I am using a JWT for authentication.
When I am authenticated, I save two elements in the cookies:
token
userId
In the Vue.js application, as long as the token exists in the cookie, the user remains authenticated, the verification is done on each new route for the front-end.
In the back-end each route waits for a valid token.
I want to create a navbar with the name of the person connected at the top right, and their profile photo for example.
This navbar appears on all pages.
For the moment in my "navbar" component I have set up an api request with the userId present in the cookie to retrieve user information.
I don't think it's a good practice to do this on all pages? Perhaps the best will be to store this information directly in cookies to retrieve it more easily?
I'm having trouble knowing what to store and what not to store cookies.
For example I will not store a user object containing its creation date, email address, etc.
I am using PHP, AJAX, and JS for my PWA development. I want the user's logged-in state to stay persistent when he/she come back to the PWA app.
Right now I am doing it via the help of the Access token and saving it in the cookie with HttpOnly via PHP. Defining it here -
User enters details, and log in to the app.
That details sent to the PHP backend, via AJAX.
Backend login code check that details from database and if matched, then code create a random hashed token.
Backend code save that hash to the cookie with HttpOnly and secure flag.
User then prompted with a successfully logged-in message.
When the next time the user comes back to the web app, the server PHP code looks for that login hashed value saved in a cookie and finds the relevant user from Database.
If a match found, the user successfully logged-in.
So now my concerns are -
Is this whole process secure and the same as what gets implemented in Industry.
If not, then what can be the best way to achieve this with security.
You can find the answer you are looking for here:)
"Keep Me Logged In" - the best approach
It is important to use an hashed cookie.
On the client side you should use a cookie that represnting the "id" of the "hashed" cookie,
When the next time the user comes back to the web app -> you will check his cookie("id") with the hashed cookie you saved on the server and check for a match(done on server side).
Note: the hashed function is done on your server.
One more thing: never let that cookie(hashed) leaves the server.
Well I am trying to build a web app with angularjs. In my webApp there is a login page aside with register page. My main problem is how to implements a login page and maintenance session with the specific user, the warning dots that came up with this scenario is when the user going to log in my web app, I will probably send a post to the server and then will get a successful result if the user and password are okay. now during the whole application the user may use his own properties like: money, friends, age, etc... now in this situation I would like to use a session that contains all of the "data" of this specific user, but when I use angularjs, because the whole thing is on the side client, I dont think its a good idea to save the password and critical information about the user in the client side, but still i need any verify information for this user, to know that he is who is he.
I don't know how to implements this scenario good when i use angularjs, with php it may be more convenient, because there is session, which stays in the server side, and I have to worry a little bit lower than using angularjs. Can someone clear this situation?
You don't want to save classified data on the client. This data has to come from the server.
This means that the angular controller that supposed to show this data must retrieve is from the server.
You should have a service that will use $http to get this data from the server using Ajax.
In order to retrieve the data for a specific user your client should send a token to the server that uniquely identifies the user.
This token will be sent to the client as a result of a successful login.
The client will keep the token in a cookie or in the local storage and add it to every http request.
Let me first start by saying that I realize that this is very similar to many other questions about service access control but I can't seem to find one response that is relevant on all of the points below, so I am asking (possibly) again.
Some background:
I am building a web application with .NET that is protected by a custom forms authentication implementation. This same app (within the same domain) needs to leverage several REST services related to data management from within JavaScript/jQuery as many of the app's functions are not well suited to post back use in the forms.
I am trying to determine the most secure way to implement access control for the REST service based on the authentication done server side when the app was first accessed.
Here is an example use case for what I am describing:
user logs into asp.net site using forms authentication and upon successful authentication the user is taken to the landing page of the application
the user chooses to access a page at ~/Users.aspx from a link on the landing page, which forms auth allows based on the cookie created by the authentication in step 1
users.aspx loads some basic HTML elements, like an empty table and a hidden field that contains a token (GUID) generated at page load. The token in the hidden field is used by JavaScript to access a REST service that retrieves data to populate the table. The token is stored in a database with a pre-defined expiration.
when the REST service is called with the token it is checked for expiration and used to determine the user making the call and provide authorization to the data being accessed from the database, if the user is authorized to access/update the data the service performs the requested service operation, extends the expiration on the token, and returns a response.
I know that the token would be visible to someone sniffing the request/response on the network unless SSL is used to encrypt the transmission, so SSL is used to counter this.
My question is:
Are there other attacks that the service would be vulnerable to?
is there a better way to handle authorization and user identification for the REST service based on the server side login other than a statically assigned token for the service? It seems to me that the statically assigned user token would be less secure since it would give endless access to the service if it were obtained by a malicious user.
assuming the answer to #2 is no, is there a better way to transmit the token to the client and store it there for the life of the page use knowing that it needs to be accessible from JavaScript/jQuery?
I have an application that uses backbone.js on the front end. So I had a question of how does it handle the user session? Everytime i send a GET,PUT,POST request, the user has to be authenticated else I get a error from the server side. Hence I used the Backbone.basicauth.js plugin which enables the basic authentication before any requests are sent across the server. I just need to call Backbone.BasicAuth.set('username', 'password');
But the problem here is that I need to hardcode my username and password everytime. So I wanted to know a way where in I can dynamically do that or a way in which I can track if a user is already logged in or i need to redirect him to a login page.
What if the user enters a random url instead of the home page, how will I track if he is logged in or not and how will I save the session?
At www.TheLadders.com we use form authentication and then drop a cookie with an encrypted token which we use to authenticate subsequent requests. We like it better than a traditional server side session approach because we can run all our servers stateless.