Can anyone tell me the best practices for keeping DB data private and only stored on the DB of a web server? I'm running a Node/MongoDB/Mongoose/Express stack.
I've got hashed password fields in the db in the User objects and obviously don't want that getting pushed out to the client end when the User data is sent out.
Currently, I'm just manually deleting the properties off of the User objects before I hand it off to Express but that just seems a bit hack-tastic. Is there a mechanism in Mongoose or Express that lets you delineate private properties that are not supposed to be sent out over the wire and only used internal to the server?
When you retrieve an object from the DB that includes those fields, then they are part of the object. Deleting them from the object before sending them out is not hack-tastic at all. Your only options are to:
delete the properties before sending it to the response
map only the fields you want to a new object and send THAT out with the response
use a different query which excludes those properties when dealing with public-facing objects
Related
I'm designing a real-estate website and I was wondering can I link my front-end webpage that shows the available properties for sale that a new property icon is added when I add to my MongoDB ? to elaborate more, I have a template for each single property which includes picture and some other info about the property, what i want to do is when i add a new collection to my database to appear on my webpage with this template. Thanks in advance
MongoDB can be watched, since your question has 'node.js' tag so assume you use node.js in the server side, I check the doc and there's a watch API returning a ChangeStream object which you may use, just for your reference
If you want to use angular for retrieving and showing data.
You can refer to these sites :
This one tells how to populate data in angular.
&
To get a crisp of doing it with mongo db
What you actually need is server side event system updating your frontend, Changestream that #user1108069 mentioned can be useful in detecting new changes or you can literally identify that when a request is being made to add a new property.
The task here is to update the frontend's current connections to update their view to get the new (load) changes, you can do this in multiple ways.
Use something like firebase realtime DB on the side Firebase Realtime DB
Use any other server side events broker for you This should work too
You can create your own full duplex system, using something like socket.io but do remember that concurrent connections needs to be handled properly. You cannot keep them connected to your server all the time.
Cheers!
I'm doing a POS(point of sale) as Saas with React in the frontend, NodeJs in backend(API Rest) and MongoDB as the database.
I've finished a basic program and now I want any user is registered will have his own database.
After read some articles and question on the internet my conclusion was switch between databases each time the frontend consume the backend(API).
General Logic:
User Log in
In the backend, I use a general database to check user credentials and also I acquire the name of the database of this user.
Each time the frontend consumes the API the next codes are executed in a middleware to know what database should use the API:
var dbUser = db.useDb('nameDataBaseUser');
var Product = dbUser.model('Product', ProductSquema);
I have the schemas and the variable 'db' defined fixed in the code:
var db = mongoose.createConnection('mongodb://localhost');
Problem:
I don't know if is the correct solution about what I am trying to make, but it seems me inefficient that the model is generated constantly each time the API is called, because in some API(i.e in some middlewares I have until 4 different models)
Question:
This is the best way? or any suggestion to face this problem?
Not sure about the idea of creating a new db for each new user. That seems to create a lot of complexity and makes it difficult to maintain, and makes it difficult to access the data for analytics and such later. Why not use a new collection per new user? That way you can use just one set of db access credentials. Furthermore, Creating a new collection happens automatically when you store data for it.
I have a basic Nodejs server connected to my ios App and firebase client. I want to fetch data from the database, which is in and system generated alphanumeric format(ex: -ibdUKV6168ded). I obviously cannot input that manually every time theres such entry, also I dont want to fetch it by having an index number of the array. How can I fetch that key.
Plus, Every time such key is generated, i want to read the document present in it.
I am out of ideas.
Any help will be much appreciated.
The database looks like this:
I want to fetch the post keys explicitly. I have a on() event called each time a new post is generated. How can I reference them.
This is solved by the firebase functions. Although, they are in beta, they are a great help. Functions along with Admin SDK provide really great combination to deal with such querying of data, where the values are uniquely identified.
I'm confused how to explain myself well here is my scenario.
I have a database named "database1" and i have used typed dataset in visual studio and have added more than 200 stored procedures in the table adapters.
it is a desktop based application. now i want to deployee the same software in other school same database but i have changed the database name
when i generate new database from query and write all the stored procedures in the database and change the database name in the connection string it doesn't work.
I'd recommend you don't change the database name, or if it's something specific to the first client (like ParisTechnicalCollegeDatabase), change it now to something generic (SchoolManager) so you never have to change it again. There's no specific problem I can think of regards reusing a typed dataSet on a different database: I do it daily on database that aren't clones of each other. Ensure your second server is set up with a user and default schema that is specified in the connection string. The problem will eithe per be faulty connection string or incorrect database setup, not the fault of the dataSet
For more targeted help, post up the error messages that appear when you try to run your app on the new database
I am using RestKit .22.0 with Core Data integration, both of which I'm pretty unfamiliar with. I followed the RKGist tutorial and was able to learn how to get objects from a REST endpoint, set up object mappings, add routes, and see the data from the web service correctly insert into the Core Data sqlite database.
Now I'm starting to work on persisting objects to the web service, but can't find any information on how best to do this. It seems like there are multiple ways to skin a cat with RestKit, so I wanted to see what the best practices are for POST/PUTing data.
When POSTing a new object, do you usually save the object in the managed object context first, then call [[RKObjectManager sharedManager] postObject:path:parameters:success:failure:]? Or is there some RestKit method that performs both of these operations at once?
If you first save the object in Core Data then POST it to the web service, is RestKit going to be able to update the already inserted object with the service's database identification attributes? Does the [[RKObjectManager sharedManager] postObject:path:parameters:success:failure:] method do this for you?
If there was an error POSTing the object, what is the typical way you'd retry the POST? Would you look for some sort of flag in the core data managed object and retry in a separate thread?
Thanks!
Yes, then the response from the POST updates that same object (perhaps filling in the server specified unique id)
Yes, updating the POSTed object is the default behaviour (you need to specify the response mapping and the response must be a single object)
No separate thread generally, and it depends what caused the error. Have a flag that indicates it's uploaded and retry when network connection is reestablished