In my angularJS application when user logs in his roles are stored in a loginService, but I have found that those values are editable by user through console.
How can I secure that?
What about CSRF handling?
I have many other security concerns with my angular/easyREST application, any useful link is very appreciated.
1) If you worried only about editing stored values, you can make them private: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Closures
I think it best you can do, but it will be possible to edit value if set breakpoint in function that have access to this value.
So you should use server-side checking anyway.
2) If you have user data in links, you should use $sanitize service before adding data to the page.
https://docs.angularjs.org/api/ngSanitize/service/$sanitize
Related
What is preferred way to share data (Object) between controllers with different routes and prevent data lost after reloading?
I need this object to prefill form values in my destination page which depends on choices in my source page.
Solutions I got so far are:
1- to send serialized Objects as query string parameter.
2- or using local storage and give special parameter to url so it knows when to fetch from local storage and when to open empty form.
Solutions which I can't use:
1- Shared service as my data would be lost after reload in this case.
Is there any other way, if not which way is more preferred?
note: there has to be no lost data after reloading page.
IMHO , there could be only 2 ways to handle this:
Using localStorage or sessionStorage
You use session management from server side keep the session consistent.
If it's just about retaining the data after page reload for a route, just go for sessionStorage. But it depends on the use case of your project.
I am using Angular2 & Auth0 to Authenticate a user.
Currently, according to their "best-practice" , the user profile is saved to localStorage , and once you need to pull information, take it from there.
This sounds like a bad practice to me, is there a better way to keep logged in profile for local query (name, photo etc.)? maybe using an Angular2 service?
The problem is if you want to keep the user profile for later use (if the user close the window and reopen it later) without having to make request to a server. Then you need to store it somewhere.
And storage facilities in the browser are quite limited: IndexedDB for database storage with query capabilities, indexes, etc, localStorage for simple key=>value storage,or even cookie for a limited amount of data as plain-text.
but if you don't need the data for a later use, you can keep it in memory (in a service, for example).
You can also combine both in-memory and offline-storage in a service.
You can combine both ways.
Storing it in localstorage to get that infos without request them anytime and wrapping a Service around it to not address the storage from everywhere.
i want my all check boxes checked whenever i come back from other pages, i want to maintain their states across pages using javascript.
I think you are asking how to store state for an individual session between requests. In this case, that state is checkbox values.
You have a choice to make first: do you want to store the data on the client (in the browser) or on your server?
Server Side
You can store this state on the server side with or without a "database" depending on how pedantic you want to be about the term.
If what you want is to avoid configuring an SQL RDBMS, you might find that the built-in storage options from most Java Servlet containers will work. In Tomcat, you can just use your Session objects as normal, but configure a "File Based Store" instead of a "JDBC Based Store." This will store session data to disk in files. Alternatively you can use StandardManager which uses in-memory storage, but does not persist session state across restarts.
Put simply, these will create a Java Map for each JSESSIONID issued by your server, and then keep the maps in memory, on disk, or in a JDBC database. For more information see: https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html
Client Side
Here you have a few options as well. The driving factor is what level of browser you wish to support. If you can tolerate restricting your users to those who use a browser with HTML5 web storage and JavaScript enabled, things are pretty easy. If not, you can accomplish the same thing with a cookie.
The big downside to client-side storage is trust. Users (or software on their computer) can modify client-side storage. This goes for cookies, localStorage, and sessionStorage. Many developers forget this and introduce security vulnerabilities because of it. If this is for a real production web application, you'll want to wrap your state in an authenticator.
Here's a the first in a three article series on a way to convince your servlet container to put session state into cookies in a way that is transparent to your servlets. It is missing authentication, but you can add it by following guidance such as this bit from Rob Winch.
Now What?
Ok. You've decided to use client- or server-side storage for your checkbox values. Now what?
A simple (usually wrong) option is to store the checkbox input names and values in a map:
{"boxFoo": true,"BarBox":false}
The reason this is usually wrong is that it fails to distinguish which form your user was visiting. It means that if you apply this strategy to more than one form on your site, you'll have to worry about name collisions.
The next evolution is to have a structure keyed by form name and then field name. This would be a map like the following:
{ "formA": {"boxFoo": true,"BarBox":false},
"formQ": {"checkAlpha":true,"BetaCheck":false } }
This works, but will have annoying behavior when your users use multiple tabs. You can make that behavior more predictable for your users by using per-tab identifiers -- at the expense of space in your session object -- or by using AJAX to keep the fields in sync -- which has its own perils. Or you can do what most people do an just assume that the last submitted form overwrites the state from all previous ones, tabs be damned. That's much simpler to code, but more annoying to users.
I can propose some ways :
send http params (in hidden field) with check boxes flags which must stay checked in each new page requested by your application . You can factorize it with a function but it stays cumbersome to do.
store the check boxes marker flag in the http session. If the check boxes must stay checked in all the life of your user, it may be a suitable solution. Use may use a backing bean session for it as you use JSF.
Nevertheless, store the minimum of information in it.
store the information in a shared applicative cache to retrieve it. In this way, you stay stateless and you have not the drawback of the session if you use clustering in your servers.
There is maybe better as alternative.
You have to bind the value with a backing bean. As long as the backing bean is having the appropriate scope it will be retained on the page when you navigate to it.
It has been some time now that i am learning and using angularjs framework, and although some of it's features are truly awesome, it seems to me as if it's key features are a bit problematic for authentication based applications.
Let's look at an example. Let's say i have a website that has a user login, and once the user is logged in he can click on a link to his/hers dashboard page. On the dashboard the user can see some private data. Now, the way i'm used to do it, is run some script on the server side and then if a user is connected, return some HTML, if no then redirect the user to another location. The way angularjs encourages me to do it is by using the route feature, say like this:
when('/dashboard', {
templateUrl: 'dashboard.html',
controller: 'DashboardController'
})
This way, in case a user is not connected, angularjs will first fetch the template HTML, then the controller will fetch some data and receive an authentication error, then redirect the route to another location. To me it seems like a worse solution for more than one reason:
1) First of all, my HTML gets exposed to everyone. Although this isn't devastating, it just seems like a bad security practice (imagine that you do not even have a facebook account, but still you can see all of facebook pages HTML, and even worse, all the objects and fields of the like for example user.accessToken).
2) I would make a larger number of requests to the server, first one to fetch the template, second for authentication validation and data, third and probably fourth for the redirection. I assume angularjs cache the templates so maybe the actual number of requests is smaller than i mentioned, still, dealing with all this on the server side is only one request - and like angularjs, it can also not load the entire page but only the needed HTML throw AJAX. My case here is arguable, but still, something about it seems wrong.
3) This is maybe the most important issue for me. Everything i do on the server side has to be pasted on the client side. For example, the routing feature must be clear on the server side as will as on the client side - in case the user enters directly to some inner page in my application, or through routing in the application links. This means that every time a change something in my routing configuration, i have to do it once in the server side, and once in the client side - which also seems to me like a bad practice and modularity of my code.
Is angularjs not recommended for these kind of applications? Should i use angularjs features that complement my applications (like controllers, variable binding and so on) but disregard and ones that doesn't (like routing)?
Do i look at it the wrong way?
You aren't looking at it the wrong way, just from a different perspective. You aren't use to developing SPA's so this is normal.
1) Sure HTML gets exposed to everyone, but that is just a template. It just contains the html template, not the specific data related to everyones facebook profile. The server controls the data that is returned to the user and it would only return the data that the user had access to see. Really this is no different to a non SPA except for the amount of data that is sent back and forth.
2) For a normal app you would first have to request the login page, then the data would be posted to the server and then a redirect would occur. This is 3 requests. With angular it would be one for the first load, second for the login view template, then third to post login data, then fourth to get the main logged in view and fifth for data required for the view. This is only two more. After that to login, if the user clicks log out and then login again it would only be two requests vs three, or if they close the tab and come back it would be 3 requests. In other words it's not that much difference. For most scenarios it will be the same amount of requests, if not less after caching.
3) The way routing works in a SPA is it only happens on the client. There is no need to have it also on the server. Just re-write the url for all request to return index.html and then angular routing will take care of the rest.
In regards to it being recommended. There are really no such recommendations. It's up to you. There are advantages and disadvantages with both. Most of the disadvantages of Angular would be related to learning curve.
Yes, you do look at it the wrong way. You mix up client- and server side issues.
Your proposed solution for authentication is, as you already said so yourself, bad from a security point of view. Delivering your HTML to the user although he/she is not authenticated is a bad idea.
Authentication always has to be done on the server side. Do not ever trust the client. That's why when you have have an unauthenticated user requesting your restricted-access dashboard.html, you sent back some HTTP error (typically 401 or 403, depending whether the user is unauthenticated or not authorized). This way, an unauthenticated user will never see the dashboard.html and your problems 1 and 2 are solved.
Your point 3 is another matter, but also invalid. There is no reason why your client and server side should have the same routing features. Routing should be up to the client-side in most circumstances. E.g., if your user manually enters http:://mydomain.org/subsite, the server redirects him to http:://mydomain.org, where AngularJS uses the appropriate routing.
So your points are not really about AngularJS being a problem for applications requiring authentication. As a matter of fact, there are many web apps out there with authentication using AngularJS. So as conclusion: No, you can use AngularJS as much as any other JavaScript technology for authenticated sites. However, if it is "recommended" (for your project) is another matter, which depends on many more factors and is beyond the scope of SO.
I have an AngularJS app running on a node/express backend. I'm using passport for user authentication.
When a user signs in or signs up, my angular controllers communicate with express via $http ajax/xhr calls. The form data is sent, node/express/passport process the data, and they return json data with the user's info (i.e. username).
Angular then uses the user info to update my templates, i.e. {{user.username}}
The problem is that if the user refreshes the entire page, Angular loses this user information. They're still logged in - req.user still contains their info - but angular doesn't know about it.
I'd like to avoid an ajax call just to check if the user is logged in. That'll be an extra http call every new visit...
I can pass the user data to the jade template directly, but that can't be updated by angular later.
I prefer ngStorage
Just check this sample example given below, enter anything you want into the text field and refresh the browser and see
Working Demo Preview
JSFiddle
Since An AngularJS module that makes Web Storage working in the Angular Way. Contains two services: $localStorage and $sessionStorage.
Differences with Other Implementations
No Getter 'n' Setter Bullshit - Right from AngularJS homepage: "Unlike other frameworks, there is no need to [...] wrap the model in accessors methods. Just plain old JavaScript here." Now you can enjoy the same benefit while achieving data persistence with Web Storage.
sessionStorage - We got this often-overlooked buddy covered.
Cleanly-Authored Code - Written in the Angular Way, well-structured with testability in mind.
No Cookie Fallback - With Web Storage being readily available in all the browsers AngularJS officially supports, such fallback is largely redundant.
I think the easiest way to solve your problem is to use ngCookies.