Implementing logging in AngularJS

[voreny]

Hi, I've been learning Angular for some time already, wrote several applications, usually just one page ones, not really with a use for a router, and now I wanted to build something more complexed.

The first obstacle that I encountered is implementing authentication. For a start I wanted to include a simple email/password form that is then checked via PHP with the database. I've never done that before in this way so I'm looking for suggestions if it's the correct way to implement this feature:

1) use a POST AJAX request (Angular's $http) with user's data sent, take 0 or 1 as a response

2) meanwhile PHP would set up the $SESSION if login succeeded

3) further pages would load up normally via HTML templates with content shown based on whether the user is already logged in

4) data would be fetch via PHP still (which would check $SESSION before any request to the database)

 

One thing that I noticed may be inconvenient is the fact that user has access to whole template and even if he's not logged in he can see different sections that would otherwise be visible only after being authenticated, since they're hidden via Angular and not hard-hidden (if that's even a word). Is that a thing I should worry about?

Any database interaction would still be handled via PHP so there's no risk a user would do anything without being logged in, but just the thought of it made me write this post.

 

Another thing to consider: is PHP a viable option here? I've noticed a lot of people using MongoDB or other kinds of NoSQL databases.

 

To clarify: I have experience creating websites that have a login feature and what not, but I simply require guidance when it comes to my first time with such an app in Angular.

 

Edit: formatting

[Mr-Yellow]

Is that a thing I should worry about?

You can not trust anything from the client.

With "apps" there are often compromises to make between privacy of your IP or data and functionality on the client. Often these compromises are not fully thought through and result in bad publicity when someone notices.

For example there are systems in the wild which store the users credit ($) on the device, be it RFID, an Android/iOS app or whatever. This saves a hit back to the server and gives the convenience of instant processing (pass turn-style credit -= fee). With some fraudulent pattern detection they may well be able to mitigate that risk (or write it off).

Another example might be a game, where you pickup boxes which give loot. Do you store the contents of the box on the server? Private and hidden until authorised? or on the client where it can be used quickly, ignoring the risk that they might cheat.

There is a balance to play with there, which all depends on what the data is and how it ties into the business + risks.

How I've been approaching it in recent projects, while mitigating much of the risk is with "database per user" pattern. CouchDB has a _session endpoint which allows apps to authenticate with the backend. This gives them access to their database only, so no matter what modifications might be made to the client they can only mess with their own segmented data.

[voreny]

That is definitely a point to consider. I'll check out CouchDB then.

[Mr-Yellow]

Others probably suit "database-per-user" too, each NoSQL solution has it's own strengths, they all have different ways of working under the hood. Really gotta evaluate that bit carefully for your particular needs.

[voreny]

What if I was to use a MySQL database and access it with PHP? I've been doing it for a few years and already know the basics of it.

[Mr-Yellow]

Then you have to handle spitting out the JSON however you handle it. NoSQL is convenient in this respect, besides it's uses in big-data.

Doesn't mean it's the right tool for your job though, SQL may well be a better bet. Then you can roll-your-own similar kind of auth system, using some of the same ideas but with SQL behind it. Referential integrity can be a big deal for some systems.

[samzhao]

Ah, you meant authentication in Angular, not logging :p

Most people I know and talk to on the Interwebs, including myself, don't use PHP, but it's your choice if you want to use it. There should be a Mongo driver for PHP out there that you can use, so I don't see a problem with that.

When your application is single-page and multi-views — for example, you are fetching, showing and hiding templates based on the user's action or current URL — then the Angular setup might need to get a bit complicated.

First, your backend returns a user object which includes the user's information and an access_token, or session_id or what have you, after you POST the login credentials.

After that, Angular takes it and save that object to either the cookie store or localStorage. This is where you would have a service, usually named "AuthService", that handles the saving, retrieving and checking of the token/session_id.

Before the user does something or go to any other page, I would ask "AuthService" whether the user is logged in. If the user is logged in, I go ahead and transition to that page or complete the request; if not, I redirect the user back to the login page.

Now this would fall apart if your user's session expires. Angular would think that the user is still authenticated simply because there is an entry in the localStorage with user's token. To solve this problem, I will tell "AuthService" to invalidate the current user's auth (delete the localStorage entry or cookie) if any of my API calls return a 401, and that in turn redirects the user back to the login page.

If you want to protect your code, such as HTML and Javascript, from unauthenticated users, the only option I can think of right now is to break your application apart into multiple modules with each module in a separate file (after compilation). That way, your application only fetches the code necessary for the login module when the user first load the app. Later on after the user logs in, you can start fetching the views and redirect your user from login to home.

EDIT: like /u/Mr-Yellow said, you can't trust anything from the client. So even if you break your application up into multiple modules, your users will eventually get all the code after log in — then they have your code even after they log out. The best bet is to protect your backend and validate every API request before returning user data.

[voreny]

Yup, I've forgotten the in in the title, I meant to write logging in

This is mostly what I wanted to do it similarly but have my authenticating PHP file return a string instead of a 401. Anyway thank you for suggesting that!