How do you hide your javascript file from showing for your client..aside from using obfuscation... do you know anyway to do this using npm and where you would just go

Var hide = require(‘hide something’);
hide(“public/my.js”);
hide(“public/my2.js”);
Hides it from clients and still able to access functions by these javascript files?

It has to be executed on the client, so it has to be on the client. Simple as that.
There is no possibility in hiding.
And you shouldn't try to.

@plusgut I have call functions such as xmlhttp request inside my javascript files and other stuff that interacts with my server files... any idea what best practices should I do to take to make it more secured?

@rui725 Security by obscurity is no option ;)
Even if he wouldn't see the executed code, an attacker still could track the requests.

What exactly do you want to secure, what is the usecase? Authentification fixes most of your problems.

@plusgut example would be I have this function inside js file changeUsr(“admin”,”username”) that changes user privilege to admin privilege by sending xmlhttprequest to server to do it and then once I got the response as text the same js file handles it.. I guess I’m not sure if what i’m doing is logically correct and secure..I’m not a web dev pro btw..

Than you should check on the server, if the user who is making this request, is authorized to do so

@plusgut does that Authorization has to do with OAuth? I’m not really sure what OAuth is for I’ve only heard of it? So you were saying that I should check my cookies that has username in side my server to do the Authorization?

@rui725 yes you can do authentification by the oauth protocol, but you don't need to and this would overcomplicate things.

You were talking about users and admins, how do you currently determine who is who? They have to login right now, don't they?

@plusgut I think I know what to do now thanks.. about the OAuth any short explanation why we use that? I mean I heard of it through the use of apps webhooks stuff like that..

@rui725 good :)

oauth is mostly used, if you want to authentificate via a third party.

@plusgut I see thanks.. Just one last question is it logical to use cookies than session? I believe you cant create session with npm right it is only applicable for php? Is it also ok to set passwords to cookies?

Wow, that's a lot of technologies you are dropping there.

First a clarification:
npm is a package manager, it does not run any code at your server. It just installs packages.

I guess what your question was: can you create sessions at node.js and/or php? Yes you can.

It is not a good practise to write a password in a cookie, in fact you should nowhere ever store a password anywhere.

What you should do: when a user logs in and you verify on the server that it was a valid authentication. You should set a session-cookie. And on the server you will write in this session that it is user xy.

P.S. just shoot if you have more questions, I'm happy to answer it.

Long story short you can’t. The best you can do is do as much computation server side as possible, then obfuscate what you send to the client.
Also good for website performance.

God dammit. Why it dont get any upvotes 😁😂😂😂

@FelisPhasma seriosly, please don't obfuscate, it won't help anybody. Just makes maintenance harder for the developer, which leads to more security holes. What would you wan't to obfuscate anyway?

Never trust the client, and do the security checks on the backend.

@Christian1998 because nobody wants to have people who try to hide stuff. You accomplish nothing by it, and it actually weakens your security.

@plusgut What I meant was running a program on your dev version of the js which minifies and obfuscates it, since the question was about hiding the js. Don’t worry, I’d never suggest working with an obfuscated version 😛

@FelisPhasma minifying at the developer build? Please don't do that either.
Sure you can have the .map file to don't fuckup your debugging tools, but what did you win?

Minifying is great for the production build, but that's the only place.

@plusgut sorry I wasn’t clear enough. That’s what I was talking about; minifying and obfuscating the production build.

@plusgut so all the minifying and obfuscation happen in production? So it is all being used as a library in node js to generate effects on the javascript files as the output?

@rui725 as I said before, nobody should obfuscate. You don't gain anything, you just loose maintainability of your own code.

As for minifying, there is no use for minifying node.js code, nobody without access to your server is able to see the executed code. It will not be transferred to a client, so there is no need for minimizing the bandwidth.

And as I said before, for gaining security minifiying/obfuscating is the wrong thing to do. Security is gained by authentication and checking what user is allowed to do what.

Got it running on heroku mind if you guys check it? Dev-learn.herokuapp.com feedbacks are all welcome

@rui725 when I'm calling the function delUser('rui725') the server always says 'deleted'. And it always says it, independently if the user exist or doesn't.

This doesn't seem to be right.

@plusgut yea still havent implemented session haha... good job on spotting that haha any other stuff I should be aware of it’s still in process :) like the posting and other stuff haha for users

@plusgut could you check on it again thanks just the session part and I was also wondering why the video background is not working on mobile phones safari and android chrome :(

@rui725 if you want me to make a small pentest, it would save me time to see the backend code as well.

@plusgut thanks!!!...anything that will help you test it faster ..i’m learning good stuff haha

@plusgut any feedbacks?

@rui725 as I said, I would like to see the backend code.

@rui725 are you going to give it to me?

@rui725 sadly I would need credentials for it

sidenote: that's a url for a git repo, this has nothing to do with the company github.

@plusgut yea I’ll give you the link tomorrow once I create a new repo with all the files in it :)

@rui725 sure thing, I have the time ;)

Do you want just the controller file? Or just the whole thing?

@rui725 the whole thing would be the best, to see the weak points.

But an disclaimer upfront: I'm not a professional pentester and I'm not specialized in security either.

P.S. Please always make a mention to my username, I mostly ignore all other notifications.

@rui725
disclaimer again: I'm not a real pentester.

I couldn't find any obvious security holes.
I have one question though, when a admin changes a user, it automatically makes him an admin if he was a user before, doesn't it?
devLearnControllers.js:231
And if I'm not mistaken all the .toString methods are not really needed, theire.

If there would be an successful attack, the attacker would have access to all the passwords of your users. And since most people reuse there passwords everywhere, that could have consequences for them. It is bad practice to store passwords at all. Better just store a hashvalue of them.

I also would recommend to use, to not name variables as single letters "t" is very confusing, could have been "translation" or something. "userType", "userRole", "privileges", or something among these lines would be better to understand the code, on the first read.

@plusgut thanks for the feedback

@rui725 you are welcome. Do you have any more questions?

@plusgut I guess there’s a need for real time changes let say you wanted to log off or block the user right? all the changes needs to be in realtime whether he is logged in or not (session) retains that idea therefore even if I was able to block them I might need to do something with their session which I dont have authority because it resides in their client browser

@rui725 correct, corrently the user would still be able to do stuff, if the session is still exiting. It works currently as a cache for the database.

@plusgut I would probably need to create a function that would always check for the status and destroys the the session whenever they interact with the controllers?

Btw yes whenever the admin changes a user privilege it always gonna be admin and vice versa... did you get to see the icon.. it looks hilarious haha

@rui725 cache invalidation is hard, I would recommend to you, to just save the userid to the session. The userid of your mongo document, won't change, so you won't need to cache invalidate it.

@plusgut so you mean to say that I should have like a separate document collection in mongo for blocked userids? And from there I should be checking if it was blocked ?

@rui725 I wouldn't really delete the user, but just add a flag to the user-document that he is blocked. This way you have a easier way of unblocking it if you made a mistake.

@plusgut I made some changes .. check it out