Nodejs: Authorization / Authentication of a superuser? Help/Tutorial/Libraries?

currently i start working with the voting app and right now concentrating on auth process. but I not getting any clear idea. so can you guys suggest any package or tutorial or any standard procedure to do this?

I believe most people get started with Passport:

1 Like

thanks for the answer. can you tell me one more thing?
let’s say I want to create multi-layer authentications group like super admin,admin, manger,user.
Different group will have different level access on the website.
In order to achieve such thing what kind of thing I should look at?

You could add a something like access: "admin" to a user in the passport.serializeUser function. That way you can always check what kind of access a user has, by checking request.user.access.

Or you could write some middleware that checks for certain access, like this:

function(req, res, next){
  // Some logic to determine if user has access
  if(req.user.access == "user"){
    res.redirect("/");  // no access
  }else{
    return next();
  }
}

Note: I have never tried this, but it should work.

1 Like

the second one should definitely work
but I was looking for something that you mentioned at first
thanks :slight_smile:

I am struggling with authentication too. I will need to check passport.

If you want an overview of how authentication is done, you can always watch this video:


If found it helpful.

2 Likes

ahh, I was watching this right now.
he can type very fast. :wink:
if you can find out any more resource please let me know :slight_smile:

@mones-cse

You said:

let’s say I want to create multi-layer authentications group like super admin,admin,manger,user.
Different group will have different level access on the website.

(disclaimer: I haven’t done this part of the curriculum yet; I am studying MEAN with A2)

Just by watching my tutorials back ( Udemy, several ) and reading some other existing info I can suggest the following.

There are several ways to solve this.

One method you can think of when coding your routers and want to assign some authentication is validating authentication of the user BEFORE giving access to ANY router that would be called down in your script.

For that you could use the Express use(...) method.

You can think on ways of ordering the routers and the use method based on an authorization hierarchy, leaving those with the full authorization capability to access all routers or to access more information.

Once you have resolved the main authorization procedure (the most common way is by using Password.js) and decided which way you want to share persistent verifiable encoded data between backend and frontend (some type of session, or jwt, or any other) you can at the backend side do someting like the following at your router script - assuming you are more into the MVC coding style pattern and the order of the routers in the script go from the least to most restricted router - let’s assume the first GET is for everyone:


router.get( "/", ( ... ) => { 
// SOME ACTION FOR A LESS RESTRICTED DATA // 
} )

router.use( "/", ( ... ) => { 
// VERIFY IF THE USER IS ABLE TO ACCESS routers BELOW; IF HE/SHE IS, USE next() FUNCTION; OTHERWISE REDIRECT/SHOW ERROR // 
} )

router.post( "/" :item", ( ... ) => { ... } )

... // OTHER ROUTERS ACCESSIBLE TO A VERIFIED USER

I think a super user will ALWAYS pass the verification at router.use( ... ) and have access to EVERY ROUTER below that method.

Another usual way is to make the router.use() authentication procedure as Middleware. In that case, for every restricted router you could check if the user is validated. Example with a get:

router.get( "/" , Validation_Middleware_using_next() , ( ... ) => { ... } )

Here you have more control over which routers you specifically want to restrict access. I have seen some times the creation of a single additional Middleware where you, after verifying the user is VALID, you verify then if HE/SHE is SUPERUSER:

router.get( "/" , Validation_Middleware_using_next() , SuperUser_Middleware_using_nex() , ( ... ) => { ... } )

But I am not sure about the above.

There are other aspects you should consider also in your frontend side so the super user has ALSO access to your frontend features too - I guess that you can wrongly prevent showing certain views to the super user if not correctly chained in the frontend.

Hope this helps?

1 Like

actually, it helps a lot :slight_smile:
thank you very much for your time :smiley: