Been learning mongodb and node. Next step I want to learn is how to authenticate users. As a beginner, what all do I have to keep in mind for this? - node.js

So far I have made a small app where you can write notes and such. A title, message, and image.
Now, I am trying to learn how to do a user authentication so that the only way to post will be after signing in to the app.
I have been looking online, but many of the concepts are quite difficult to understand. I already have a user model, so what all things do I have to keep in mind to authenticate the user? How do you pass the username and password for example (plain text is bad right?)? Etc.

My suggestion to you is to start with a pre-configured template like MEAN stack - where you can lean by example.

Related

How to make a proper and simple authentification for nodejs website?

I am learning to make a website with nodejsn, express, socket.io and mongodb. I am pretty much self-taught but when it comes to authentification, I can't find a tutorial that explains how it works in simple terms.
I have a login form, a signup form, the user data is stored into the database on registering. When I login, the page greets me with my username, but when I refresh or close the tab and come back, I have to login again.
All I want is that make users able to come back without having to log in systematically.
All I can find are explanations like : http://mherman.org/blog/2015/01/31/local-authentication-with-passport-and-express-4
And I don't really get it.
Can someone explain what am I missing here ?
Session management is something that Jekrb highlighted and is also a great question when it comes to highlighting users if it be anonymous or users of your application.
Though before I go into any depth I am going to highlight that cookies have a slight problem if your application is going to work on a larger scale where you have this scenario: "What happens if you have N servers where N > 1 ?" so to some degree if your unsure of your user-base, cookies may not be the correct approach.
I'm going to presume that you don't have this issue so providing cookies as a means of identifying users is appropriate, but isn't the only method available.
This article outlines a few ways in which the industry tackles this:
https://www.kompyte.com/5-ways-to-identify-your-users-without-using-cookies/
My favorite method here would be canvas fingerprinting using https://github.com/Valve/fingerprintjs2 Which will create a hash that you can store and use to verify new connections, Probably with something like socket.io which you've listed as using. A major upside of this is scalability as we can store these unique hashes centrally inside of the database without the fear of always being stuck with one server.
Finally I haven't posed any code which I dislike but the topic is hard to pin down to specifics, though I have hopefully offered some alternatives to just cookies.

Best way to store answers from users in Facebook bot chat?

Building a Facebook messenger bot using Claudia JS and plan on hosting on AWS Lambda.
I want to ask the user a series of questions.
When a user responds with an answer, I need to save that for later and once I have all the information I need, I will pass the answers to a function.
What is the best way to save this information?
I was thinking some caching layer such as redis but because that is stored in RAM I will lose it when lamda server shuts down. Mongodb apparently has a lot of overheads when connecting but will at least be persistent.
Perhaps just a simple mySQL server?
How does everybody else do it? I feel like there is a simple solution that I am missing.
I will first answer the part about how I'm doing it: I'm using a MongoDB. I toyed with the ideas you mentioned, but quickly crossed out in-memory solutions (Memcached, Redis) with the same reason. My final solution came down to either a relational DB or a noSQL like MongoDB. To be honest, at my project's scale, I did not think about robustly comparing performance between DB types.
With my particular feature "roadmap," I decided to go with Mongo to approach a more "OOP" style when dealing with the user "object" without having to explicitly define a user class, thanks to the normalized structure of Mongo. I understand the same could be done for MySQL, too, just that processing json data is more "object-like" for me and flask, i.e. user = getUserFromMongo, which gives me a dict in Python then I can just do user['first_name']. The codes belows will explain this simplicity:
(Somehow this was feeling like... not having to write SQL commands for simple database interaction in Rails)
My user object data on MongoDB
Finally, as to how I manage user input, I adopted Wit.ai's concept of context. I don't know how they do it exactly, but a context to me is the type of conversation purpose that is going on. I use it like a stack, and as soon as the current context is done, pop it off the context data of the user. For every message the bot receives, the program will get the current context and direct the flow. Whenever an unknown error occurs (exceptions handling), most likely because the user is saying something the bot doesn't understand, I clear the context data, too.
The good part about MongoDB is that I can shape the context however I want and treat it just as an object. A simple one is like {name: yelp-search, stage:ask-for-user-location}, and I imagine complex ones could be built on that structure, too. Of course, a stack implementation of the context does not deal with complex conversation with complex past reference.
I put my project on Github if you want to take a look at it.
i have also used mysql for chatbot but i have used NodeJS for the backend app.For that mysql module would be very helpful.
You need to store users' current state for the question answer session and also store the answer itself from the user and you need to make a switch or if-else-if case for asking questions to user based on its state as switch(state) and in cases of switch just update it's state.and you have user's facebook-id in event object of chatbot so that you can store data of each user individually with their state and question-answer in different table.
For e.g. define flags{1,2,3}
user's state will be 1 in begining so ask him for e.g. question-1
only,and store this as answer-1, you can do this by it's state
checking, and after this update status to 2.
so,in this way you can ask each individual student question as per
their state and answer him.
I've done the same in exact above manner.
Hope this would be helpful to you.

Authorisation strategy for a first-party express based node API

I'm tackling the design of my first API and am struggling somewhat with authorisation concepts - I was hoping some kind people could give me some advice!
What I'm building:
An API that will eventually be accessed by third party apps and a mobile app.
A web-based 'client' (first-party single page app) that will use the API. (Should this first-party app be 'a part' of the API, or a completely separate node app?)
Technology I plan to use:
Node
Express
Passport
Mongodb with Mongoose
I'm not wed to express or passport, they just seem like the best options and are well documented - bit I wouldn't want a potential solution to be dismissed because of alternative dependencies. Same with Mongoose, I actually prefer the look of Monk (or even just Mongojs), but every tut seems to use mongoose, so seems like the safest option for a node beginner.
Authenticating a user is simple enough (I've gone through the fantastic Beer Locker tutorial), what I'm struggling with is ongoing authorisation. Naturally I don't want the user to have to input a username and password with every request they make - should this information be stored locally and sent with every request? (if so, how? I can't find any info on handling an API with a session) or should I be working with tokens of some sort? The small amount of reading I did on 'Digest' authorisation (including the Beer Locker tutorial follow-up) made it seem like it had security issues, at least with the Passport implementation (this I don't fully understand, but seems to relate to hashing passwords, which passport doesn't do as standard, and only MD5 is supported even if it's added?).
I have built a working API that I can authorise with 'Basic' (directly, through Postman), so I have the foundations in place - authorisation works, I just need the tools to take that to the next step and add sessions into the mix!
I've been trying to get my head around this for a couple of days now, but I fear I'm too stuck in a more traditional local web-app workflow - the whole API thing is throwing me somewhat.
Any help is hugely appreciated, even if it's just pointing me at an appropriate tutorial - the above set of requirements must be quite common!
I have come accross this problem too...
I can only recommend doing this for the beginning:
http://scotch.io/tutorials/javascript/easy-node-authentication-setup-and-local
tell me if it helped :)
As I understand you have done the authentication and the only thing you have to do now is store somewhere that the current user is authenticated, his name, roles etc to use later with other requests. In the Passport you will do it in the function callback (instead of the "If this function gets called..." comment).
Now you have to decide, you have two options:
Store the user information (name, roles etc.) on your server (in a session) and give the user some long code which will identify his session for the next requests
to store the information on your server you may use for example the express-session middleware
it would be probably best to save the session identifier in a cookie, but read some security issues before
Give the user something that would prove to you he/she is authenticated and which name, roles etc. he/she has
you can generate a token, that contains the user information (name, roles etc.) that the user will send with every request. to know this token is legit, you will have to sign it. more on this is on jwt.io and you can use express-jwt middleware.
you dont have to care about storage of session with this one
the token can be placed to a cookie too, but same security issues apply. it is still considered better that localstorage (more here)

mix two templates together

I own this website : http://www.[my site].com/ and I have a forum for it : http://www.[my site].com/vb
I want to mix both so ... if somebody logged in from the website he will login in the forum.
my problem is that the forum user login ... uses an md5 password encoding but it is different than the md5 password incoding in my website ... how I can make both of them use the same encoding ? btw ... the forum template is too complicated.
note : I did combine both templates on one database.
One approach is use the "Proxy Connect" approach pioneered by Vanilla forums:
http://vanillaforums.org/docs/singlesignon
Another approach, since I assume the VB in your forum's link stands for vBulletin, is to look for an SSO (sing sign on) plug in or a developer to assist with this process.
You say that you "combined both templates on one database". I'm not sure what this means but you should be able to delve into the code and encrypt passwords in the same way....or combine/mirror the password for each user's forum password with the password on the main site. The proxy connect approach outlined above is probably better.
Finally, you could do nothing at this time and wait to see if your forum catches on. If you are able to get traction then perhaps it warrants an investment in time/money to streamline the sign on. However, in my experience, users have no qualms about creating a separate account to join a forum provided with fresh and compelling content. I'd focus your energy on seeding the forum and making it interesting/active/lively.
Good luck!

CouchApps and user authentication

I posted a variation of this question to the CouchDB user list and haven't received a response yet.
I'm curious to know if anyone else has built a so-called "CouchApp"; a pure HTML/JavaScript application hosted directly within CouchDB. If so, how did you handle user authentication? I'd like to be able to create a typical login form (username, password) and then use those credentials either against a view or some other mechanism before passing the user along to the application (while storing their (encrypted) user ID in a cookie, presumably).
I'm used to simply proxying through something like couchdb-python and a normal web server, but would like to know any best practices with respect to authenticating users in these kinds of CouchApps.
Edit: A year later, and this is now built into CouchDB. This video is a great demonstration. (Thanks Daniel!)
CouchDB has released a simple authentication api but has no in built authentication mechanisms as of yet. The simplest and easiest way to do this is to use an http proxy for authentication. However this has limitations on how much you can restrict access on a per document basis. When CouchDB gets some more support for built-in authentication modules then it should be easier.
If you want to try your hand at coding an authentication module then you can check out the source for the javascript security_validation tests in this file:
http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch_tests.js
and the default_authentication_handler in this file here:
http://svn.apache.org/repos/asf/couchdb/trunk/src/couchdb/couch_httpd.erl
that would get you started anyway.
This question has been around for a while (1.5 years!) and things have matured quite a bit since it was answered. Watch the video above, but it doesn't explain how to build it into your app. It looks like most of the answers are now found here: Security Features Overview and at the end of this document: CouchDB Security.

Resources