Express.js: user access just the data created by them - node.js

Im struggling with Express.js and MongoDB.
I already configured passport login and passport-jwt, and it works just fine, but now I have a problem.
For example I have two users and one table, and I want when the first user login in the application, they have access the data created by them.
What is the best solution for this? Create one table per user?
Help me out and I appreciate your help!

you can update your schema of data that will be stored inside table, by adding:
owner {
type: mongoose.Schema.Types.ObjectId,
ref: 'User'
}
while user will be the name of modeling that created as users database, so every data inside that table will have id of its owner, and every time you want to display that data or send to the user, you can check if id of the owner of that data equals to the id of the user already login, and depend on that you can display the data of table or not.
and the id of the user will be stored inside req.user._id which will be created by passport package.

Related

Setting PermissionModes in Azure CosmosDB

Hi I working on a simple application using Azure CosmosDB. Now I want to use resource tokens to provide specific access to documents and collection in the DB. In the permission modes there are PermissionMode.Read and PermisssionMode.All. So I am assuming that PermissionMode.All allows the users to read, write, delete and post. If what I am assuming is correct, I specifically do not want my users to delete or post in a certain collection. How do I achieve this?
For better understanding, my database contains a container called users, which contains user information along with their posts and likes per post and stuff. Now I allow all my users to read (view posts of other users) and write (give a like or increment the like field), but I want to allow Post and Delete to a document to only the user of the document.
The finest granularity for assigning permissions is a partition key value so the only way to grant per document permissions is if your document id is also the partition key. If your partition key is userId and the user profile and posts, etc. all share that same partition key then that should work for you. Here is a sample that creates a permission on a partition key for a user.

Scenarios definition for JWT/API Process with Cucumber/Behat

I have a scenario where basically:
- Authorized (JWT) user access my API
- If user exists, info get synched with DB, if not, gets created
- ETC ETC
My question is, how would I proceed creating this scenario? There's a lot (ok, 4) parameters that should be in the request, but I don't want to polute the scenario with information that can confuse a normal user reading the scenario.
This is what I have:
Scenario: Non Existent user access the API
Given an authorized user access the API
And user does not exist on API database
When user access the API
Then user details are added to API database
And user does exist on API database
A user accessing the api will have: email, auth0_id, nickname and name. Just not sure if I should code those info on the Scenario or somehow do it on the Context file.
Edit:
Can I have some "parameters" to be set IN the Context file, instead of in the .feature file? i.e. On the feature file I say "Non existent user access the application" and inside the Context file, in the function associated with this step, I make sure I create a user that does not exist on the database and so on? Would this be a good way of keeping thinks separated from the .feature scenarios?
Thanks
I would write it like this:
Scenario: API - new user access the API
Given I have a new user
When I access the API with the new user
Then the user is added to the API database
First step would generate the user details and save them in a variable, second would make the call to the api (using the saved variable and generate the JWT) and the last one will check the details in the api.
You can declare new as parameter like:
#Then /^I access the API with the (new|other_user) user$/
Anyway, you should declare it as simple as possible in a manner that has sense to you can that you can easily reuse.

Temporary User Accounts: MongoDB vs Redis

I'm developing an application with NodeJS, ExpressJS and MongoDB. Currently I'm working on the user registration process. I would like to store the user account temporary until the user has verified his email address, if the email address is not verified within a certain amount of time, I would like to remove the temporary account.
Currently I've following two ideas to solve the issue:
Creating a mongoose TempUserModel (besides the UserModel), i.e. if the user does the registration a temp user will be created, as soon as the user verified his email address, the temporary user account will be copied to the real Users collection. Some cronjobs could be setup to delete not verified user accounts after a certain amount of time (probably there are better solutions to let expire a mongodb record)
Setup redis to store the temporary user account data, as soon as the email address get verified, a new user will be created in mongodb. With this solution an expire date could be set to remove not verified accounts after a certain amount of time)
Is it better to store a temporary user account in Redis or in MongoDB?
I would recommend storing the temporary user accounts in MongoDB. Storing them in MongoDB has three advantages over Redis:
If you store a temporary user in MongoDB, it will be very easy to convert them to a real user once they have verified. In fact, you could even have the temporary users and verified users share the same schema, with a has_verified field in that schema being the only difference between the two kinds of users. Changing has_verified to true is a lot easier than saving data from Redis to Mongo.
If you are not already planning to create a Redis database for your project, you will only have to maintain MongoDB. Maintaining MongoDB requires less effort and fewer computation resources than maintaining both Redis and MongoDB.
If you ever make changes to your user schema in the future, it would be easier to only make those changes in once place, i.e. MongoDB, rather than to make those changes in two places.

MongoDb: How to merge contents of two documents in mongoDB?

I allow user to skip login or login using FB. When user logs in I create user in User collection using FB profile ID and when he skips it I still create his user using some unique client ID. In the client app, user can bookmark articles and I sync it to server. User can login using FB at any time later. Once user logs in using FB I have to merge user created using FB and user created using Client ID so that his stored data maps perfectly.
What I have tried:
Consider user skipped login and I create a user in USER collection.
User logs in using FB in between life time of the app and I will search this FB ID in my collection. If this ID does not exist I update skipped user document with FB id. If it exist I will merge data from FB user document to skipped user document and delete FB user document.
Another method:
I don't sync any bookmark to the server until user logs in. Once he logs in I will sync all data at once.
What is the efficient way of doing this kind of operation?
If I understand correctly, you need to find the document with the same clientId, and add to it the facebook user document.
You can do this with mongo update command, using $set which merges the new document with the existing mongo document https://docs.mongodb.com/manual/reference/operator/update/set/
so your code would look like this
db.collection("users").update(
// first parameter is mongo query to match based on clientId
{ clientId: 100 },
// second parameter is the document that will be merged using $set
{ $set: facebookDocument })
The result of this will be the existing document merged with all the properties of facebookDocument

Get deleted user information from sharepoint

Is there a way to get a user name of the user deleted from sharepoint? I have the id of the deleted user. I need this since I want to present a more user friendly information taken from the audit logs. There I have only the id of the user.
You should be able to find the information in the content database (the UserInfo table), I'm not sure wether you can get it from the object model though.
Remember Microsoft does not recommend directly querying the database though...

Resources