I have a webpage which has a form which allows users to add comments to the page to give feedback.
https://express-chat-comment-ap.herokuapp.com/feedback
You'll notice a user can delete comments, not only their own comments, but all of them.
So my question is, how would you limit those privileges to only that current user?
There is a major piece to all of this which is the web page is being integrated to a website which has a user login/user account already.
Also do I have to do any research regarding what back end their using now? Or can I keep this all encapsulated with Express/Node?
What packages should I use?
Where do I start?
Thanks in advance for your help!
You're putting the horse before the cart. This isn't really a "Node/Express" question; you're not going to solve it at the Javascript level.
Instead, your main question is actually "How do I do 'security'?"
More specifically: "How do I 'authenticate' users?" "How do I grant access?" "How do I prevent access?" And so on...
SUGGESTIONS:
User Authentication with the MEAN Stack
MySQL Authentication using Passport
OAuth 2 Single Sign on Authentication with Passport
Node.js: Token based authentication
Heroku: Managing Organization Users and Application Access
You must have an authenticated and logged in userID for each user that your server authenticates and understands. Each comment must be saved with the userID of the creator and you must be able to retrieve that from your data store.
Then, your server can check who the user is that is attempting an operation (probably from a logged in cookie that accompanies the request), what the operation that is being attempted and decide if that operation is allowed by that user. For example, if the user logged in is "Bob" and they try to delete a comment from "Alice", then the server will refuse to carry out that operation.
And, your UI in the web page can not offer operations that are not allowed (though the server must always check anyway). So, if you have a delete button in the comment, you would only show that button on comments that belong to the current user.
Related
I am designing api for mobile application.
I am not sure should I have one endpoint login which will return tokens & user profile
Or have two endpoints and after login call getProfile endpoint.
I saw that people mostly use second option but I don't see benefit of that approach?
Thinking in terms of the single-responsibility principle (which basically says "API methods should do one thing really well"), I'd suggest separating these into two separate things:
POST /login would set up a session and return the session ID to be used in subsequent requests.
GET /profile would return profile information provided a valid session ID is provided.
There are obvious benefits along the "happy path" for combining these, mainly the fact that after a login operation completes, you automatically provide the user with the data they most obviously would want next (who the user is). Why waste an extra API call to find it out, right?
If that's all your API will ever need to support, then there's no reason to separate these. But there are a couple cases I can think of for why you might want them separate:
What if an existing and already logged-in user wants to fetch the latest profile information? This means you must support GET /profile anyway (or have them POST /login again which is wasteful).
What if profile information is already cached and the POST /login API call is only happening to re-authenticate the user inside the app to complete an action? You'd be wasting bandwidth by sending data that's not needed.
Additionally, testing is usually a bit easier when you have each API method doing the one thing they imply they do (POST /login logs the user in, GET /profile fetches the current logged-in user's profile).
I'm trying to implement a GET method with Express in my nodeJs application.
I'd like to do something like this in order to display user data :
router.get("/user/:idUser", (req, res) => {
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
How could I proceed ? I thought about using some encryption process to have something like :
/user/PdfgdfJFDGTfrfgdsf
Your question isn't really making sense. You don't want authentication, but you only want a user to be able to view their own data so nobody else can view it.
The ONLY way to solve that is by using some form of authentication. The user has to prove to the server that they are allowed to view that data before the user renders the page for them.
Yes, you could obscure the URL (make it some mostly unguessable string of characters), but it's not clear what problem that is solving. The user themselves won't be able to remember it or type it so it would probably have to be a link in a web page and if it's a link in an unauthenticated web page, then anyone can get to it - thus defeating the purpose.
There are cases where temporary links (often done for privileged downloads) such as what you mention /user/PdfgdfJFDGTfrfgdsf are sent via an authenticated channel (either an authenticated webpage or sent to an email address known to belong to an authenticated user) and these links contain some unique and hard to guess code. The user can then click on that link (in authenticated webpage or in email) and access that resource without further authentication. In that case, the knowledge of the code in the URL is serving as a form of proof of authentication. Because URLs may be logged in service providers or corporate infrastructure and thus not remain entirely private, this technique has its limitations and is typically only used for short term (download this resource in the next 10 minutes) type of uses, not a long term substitute for authentication and not used for things that demand real security. You don't explain enough of your use case to know whether this is practical for your situation or not.
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
That's an inconsistent statement. You say "user doesn't need to be authenticated in order to execute this code" and then you say "I don't want that anybody can execute this request with a user id of someone else.". You can't have both. The user is either required to prove authorization or they aren't. Pick one. It can't be both.
you can use jwt for this and a auth middleware for this
upon decoding jwt token, you can implement logic to check if the decodedToken.user_id (given that you add user_id when encode token payload) is equal to the :idUser in route (or any kind of logic you want) there.
I've spent the better part of the day trying to figure out how OpenID works. My goal is to set up a simple site where, upon clicking a login button, users are taken to a Steam login-page, where they are prompted for username and password. After successfully logging in, the user is redirected to a page on my domain, where I collect the query string parameters. They look like this:
{
"openid.ns": "http://specs.openid.net/auth/2.0",
"openid.mode": "id_res",
"openid.op_endpoint": "https://steamcommunity.com/openid/login",
"openid.claimed_id": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.identity": "https://steamcommunity.com/openid/id/7656119[0000000000]",
"openid.return_to": "http://127.0.0.1:8000/resolve",
"openid.response_nonce": "2018-12-01T14:49:46Z30hhn2/[someTEXTendingIN=]",
"openid.assoc_handle": "1234567890",
"openid.signed": "signed,op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle",
"openid.sig": "[someTEXTandNUMBERSendingIN=]"
}
What I am unable to solve though, is the actual authentication issue. I'm not sure what to do with this data. I want to have my own database where I store more information about the user, such as friends, messages, currency etc. For this, it is very important that I can verify that someone didn't just take this request body, change their ID for another and in that way access their account.
I'm pretty sure these are the relevant pieces of documentation, but it still isn't clear to me. How am I supposed to authenticate the user with this data?
I've omitted some values in this post that I fear could be bad to share. These placeholders have been outlined with brackets []. Also, that assoc_handle is really 1234567890, which kind of puts me off, since according to the OpenID documentation, it is used for determining the signature.
To be clear: this page where credentials are collected is not run by me, but is the official OpenID sign-in page for Steam. Steam is a gaming platform. https://steamcommunity.com/dev/ for reference.
For Steam authentication in nodejs you can use Passport.
Passport is an authentication library that works best with Express-based web application.
There is a steam-strategy that can handle your steam authentication.
Check passport here
And this is the Repository for Steam strategy. There is an example folder that you can see how to setup your Steam authentication.
I have a Spotify app and want to persist basic settings per user between sessions. I see the User object has a username field, so it would be easy to do this using my own backend. My question is, is this allowed, without requiring the user to log in, agree to some TOS, etc? Every app I see that persists any data requires me to log in with Facebook.
Usernames are typically obfuscated out in the Spotify API, so they're not the best thing to use. However, the anonymous ID for the user is the same for a given user/app ID combo across multiple machines, so you could use that instead. This sort of thing is what we designed the anonymous ID for, so you're good to go on the ToS front.
I can't find anything that restricts you from load/storing data from your own servers and I've seen 'you'd have to use your own server' suggested in a number of questions.
Not sure why other apps would involve FB - probably to get more info from the user or promote their product.
You should use the User's URI instead of their username though. I would expect it be more stable than the username and less likely to be little Bobby Tables.
I'm writing a GWT application where users login and interact with their profile. I understand that each form entry needs to be validated on the server, however, I am unsure about potential security issues once the user has logged in.
Let me explain. My application (the relevant parts) works as follows:
1 - user enters email/pass
2 - this info is sent back to the server, a DB is queried, passwords are checked (which are salted and hashed)
3. if the passwords match the profile associated w/ the email, this is considered success
Now I am unsure whether or not it is safe to pass the profile ID back to the client, which would then be used to query the DB for information relevant to the user to be displayed on the profile page.
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
-Nick
What you are dealing with here is a session management issue. Ideally, you want a way to keep track of logged in users (using random values as the session key), know how long they have been idle, be able to extend sessions as the user is using the site, and expire sessions.
Simply passing the profile ID to the client, and relying on it to send it back for each request is not sufficient - you are correct with your concern.
You want to keep a list of sessions with expiration times in a database. Every time an action is executed that needs user permissions (which should be pretty much everything), check to see if the session is still valid, if it is, extend it by however long you want. If it is expired, kill the session completely and log the user out.
You can store your session keys in a cookie (you have to trust the client at some point), but make sure they are non-deterministic and have a very large keyspace so it cannot be brute forced to get a valid session.
Since you're logging a user in, you must be using a backend that supports sessions (PHP, .Net, JAVA, etc), as Stefan H. said. That means that you shouldn't keep any ids on your client side, since a simple id substitution might grant me full access to another user's account (depending on what functionality you expose on your client, of course).
Any server request to get sensitive info (or for any admin actions) for the logged in user should look something like getMyCreditCard(), setMyCreditCard(), etc (note that no unique ids are passed in).
Is there a possibility for a potential user to manually provide this profile ID and load a profile that way? My concern is that somebody w/ bad intentions could, if they knew the format of the profile ID, load an arbitrary amount of information from my DB without providing credentials.
Stefan H is correct that you can solve this via session management if your session keys are unguessable and unfixable.
Another way to solve it is to use crypto-primitives to prevent tampering with the ID.
For example, you can store a private key on your server and use it to sign the profile ID. On subsequent requests, your server can trust the profile ID if it passes the signature check.
Rule 1 - Avoid cooking up your own security solution and use existing tested approaches.
Rule 2 - If your server side is java then you should be thinking along the lines of jsessionid. Spring Security will give you a good starting point to manage session ids with additional security features. There will be similar existing frameworks across php too (i did not see server side language tags in the question).
Rule 3 - With GWT you come across javascript based security issues with Google Team documents and suggests XSRF and XSS security prevention steps. Reference - https://developers.google.com/web-toolkit/articles/security_for_gwt_applications