node.js - The "right way" to architecture voting with Mongoose? -


i'm creating web app using mongoose/mongodb store information voted on. i'll storing usernames , ip addresses vote (so voters can update/modify votes if desired).

root question: what's best way securely architecture voting in mongoose schema?

currently, schema looks (simplified):

var thing = new schema({   title: {     type: string   },   creator: {     type: string   },   options: [{     description: {       type: string     },     votes: [{       username: {         type: string       },       ip: {         type: string       }     }]   }] });  mongoose.model('thing', thing); 

while makes querying db given thing super easy, becomes more problematic security obvious reasons - don't want returning out usernames , ip addresses browser.

the problem is, i'm not sure best/least painful scenario securely returning thing data browser:

  1. loop through each option in thing.options, sub-loop through each vote in thing.options[i].votes find vote cast user requesting data, delete votes rid of other user data. seems resource intensive, couldn't find way use indexof in subarrays (guidance welcome on one), i.e. thing.options.votes.indexof(username) or effect.

  2. store vote information in already-existing user schema, have search through users vote data , stick every time want query single thing. seems inefficient/more resource intensive/more complicated necessary.

  3. create separate vote schema stores data more conveniently, adds database call (one thing, 1 vote).

this problem compounded fact there different ways vote, being simplest.

research...for posterity's sake:

this question addresses voting in databases, relational db, not mongodb/mongoose.

this question addresses mongoose/node.js app architecture, nothing votes.

this npm module adds voting mongoose schemas, doesn't quite fit needs.

this post looks promising, author sort of doing i'm describing in point 1 above (see listing 13 on author's post), still creates nested loop, starting in line 22 of listing 13, loop through each choice/option, through each vote each choice/option.

as quick hint - prevent leaking of ip addresses db - suggest add collection store vote sensitive data, still have other vote data in same document.

this gives small overhead when storing data, design ip info not provided caller , there no need data scrubbing on every call, secure data.


Comments

Popular posts from this blog

ios - RestKit 0.20 — CoreData: error: Failed to call designated initializer on NSManagedObject class (again) -

java - Digest auth with Spring Security using javaconfig -

laravel - PDOException in Connector.php line 55: SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost' (using password: YES) -