Extention on $http methods about angular-client-side-auth

[fnakstad]

Thanks again for the input. I've actually been thinking of adding more content to the individual pages to make it feel more like an actual site, so a list of users could be interesting for the admin page.

If I read you correctly by "extensions to the $http methods" you simply mean that you want to see more examples of XHR's to fetch information from the server? I don't want to bog down the application with too much functionality that's not related to authentication/authorization since that's what it's supposed to demonstrate. But I will add some simple examples to get more content on the site. In this connection, I think it would also be interesting to expose an XHR which always returns 401, so that the user can see how the HTTP response interceptor works.

[Kahramon]

Hello Frederik,

yes, you are right that the keeping the things simple and clear is always good idea, however in the above post I meant simply to give complete examples for $http service as you have only $http.post method used. Therefore to use other methods($http.get, $http.put, $http.delete) in addition to the $http.post I gave you the above scenario to use the mentioned methods as you have already static users data to retrieve.

For example, extend your service to get users and to read a specific user use:
getUsers: function(success, error) {
$http.get('/users').success(success).error(error);
},
readUser: function(success, error) {
$http.get('/user/' + $routeParams.id).success(success).error(error);
}
and so on to edit/delete user ...

So you have everything and just to play with $http methods. Additionally, I think this would be useful for beginners and also related to your app's purpose as admin can do read/edit/delete users. It is interesting, right?

Kahramon.

[fnakstad]

Yep, overall I think it's a good idea since it will also help add some more content to the presently blank pages. And the users listing you mentioned seems like a natural candidate for this. I'll take a look at it this weekend :)

[Kahramon]

Very realistic scenario could be:
a) when a user logs in, he can only see the user's list and details of any user without editing or deleting;
b) when admin logs in, he can additionally edit and delete. Of course, in your case you should pretend deleting your use cases admin/123, and user/123.

So, in this way you can proudly proclaim that your application also supports fully CRUD functions additionally to the authentication/authorization -> your application will be rock, trust me :-).

[fnakstad]

Ah, there is one problem with this though! If I implement this it would mean that anyone can register an admin user and then delete the users of other people who are trying out the demo. So, I think it would be better to introduce a resource other than users which could have CRUD operations performed on it without worrying about anyone messing up the demo for someone else.

[Kahramon]

Yes, it is right.

[fnakstad]

I just pushed out some fairly big changes now though they're not very visible on the front-end yet. The admin page now displays a list of users, though the presentation is quite horrible right now :p There have been some big changes on the server-side to prepare for creating more feeds to serve data to the client as well as authorization/authentication middleware added. I haven't updated the live example on Heroku yet, but will once I add some more changes this weekend.

[Kahramon]

I just checked -> very good job!

[Kahramon]

Hi,

I am encountering some problem here - not always. Checked with 2 browsers. The browsers display
[object Object].

Here the server's output:

"C:\Program Files\nodejs\node.exe" server.js
Express server listening on port 8000
[object Object]
GET / 500 19ms - 15b
GET /favicon.ico 500 2ms - 15b
[object Object]

I would say, the problem here with cookies - restarting the server does not help. If I clear all history of web bowser it works again.

[fnakstad]

Hmm, yea. I thought this occurred only if you still had an old cookie with the name "connect.sid" in your browser, but it seems that's not the problem. I'll investigate a little further.

[fnakstad]

By the way, have you found an easy way of reproducing the problem after you've cleared your history?

[Kahramon]

I have no exact way how to reproduce the problem, but I guess that if I am logged in and change something in the code and restart the server or something like, it occured me at least 3 times while played with it. However, if occures again I will give you details.

[fnakstad]

Okay, I'll try to as well. And as always thanks for helping me uncover bugs :)

[fnakstad]

I figured this out, and committed the fix in c78df42. The steps to reproduce the error were as follows:

1. Register a new user. This logs in the user automatically and sets a cookie session in his browser.
2. Restart the server. This will cause the in-memory stored users to be deleted.
3. Refresh the browser window and get the nasty error message we discovered. This is displayed because Passport wasn't able to deserialize the user in the cookie since he now no longer exists on the server-side.

The fix I just committed causes Passport to delete the entire server-side session if a user can't be deserialized.

[Kahramon]

Very good!