asp.net web api - Hot Towel/Durandal/Breeze.js: how to vertically secure data calls? -

i'm new whole client-side spa world. i'm using above technologies, seem quite promising. however, 1 huge snag can't on lack of built-in security. had manually roll out user authorization, imho should part of framework.

now have sorted, i'm getting major headaches vertical security: 1 user logged in can access other users' info changing few parameters in browser console. pass userid every call , compare 1 on server, hoping there overarching solution doesn't pollute breeze data calls user ids.

for example, let's there's call data service this:

function getitems(){                  var query = breeze.entityquery.from('items').expand("person");          return manager.executequery(query); } 

this items, not good. let's limit userid:

function getitems(userid){                  var query = breeze.entityquery.from('items').where("userid", "==", authentication.userid).expand("person");          return manager.executequery(query); } 

in second example, userid authentication service, stored userid when user logged in. however, malicious user can go browser console , change value.

of course, pass userid using withparameters(...) , compare current 1 on server, i'd have every call, doesn't seem right. there better way secure calls trusted user id?

@ali - understand pain , concern. right fear form of so-called security relies on information passed in url. fortunately there excellent answers concerns , breeze apps work them.

for example, have studied asp.net breeze/knockout template? uses forms auth authentication , guards web api controller [authorize] attribute. logged-in users can access of controller methods.

that authentication sets iprincipal web api controller makes available through user property. you'll see user passed constructor of todorepository. in repository you'll find guard logic restrict query , saves todo information belonging requesting user.

look @ network traffic. won't find user identifying information in url or request/response bodies. see encrypted authentication cookie in header.

an obvious flaw in example client/server traffic takes place in clear. must add transport level security (https) before go production. demo after all.