Sunday 15 August 2010

Firebase security rule to prevent customers from circumventing usage tracking -



Firebase security rule to prevent customers from circumventing usage tracking -

we offering service people embed on web site , hoping utilize firebase our backend. base of operations our subscription rates on page views or similar. right stumped trying figure out how prevent customers caching our client js code , omitting portions effort increment page views counter.

what need somehow create security rule atomically prevents reading 1 location unless have incremented counter @ location. ideas on how this?

for example, assuming next schema:

{ "comments" : { "-jylv8kqgkuk18-nnyhk" : { "content" : "this first comment." }, "-jylv8kwnlfzhlbophfo" : { "content" : "this reply first.", "replytocommentid" : "-jylv8kqgkuk18-nnyhk" }, "-jylv8kbt63wl9sb0qvt" : { "content" : "this reply second.", "replytocommentid" : "-jylv8kwnlfzhlbophfo" }, "-jylv8keltmbr7urk08y" : { "content" : "this reply first.", "replytocommentid" : "-jylv8kqgkuk18-nnyhk" } }, oldpageviews: 32498, pageviews: 32498 }

what way of allowing read access comments if client first incremented pageviews field? @ first thinking having 2 fields (something pageviews , oldpageviews) , starting out incrementing pageviews, reading comments, incrementing oldpageviews match, , allowing read on comments if pageviews === oldpageviews + 1. however, unless done atomically, info corrupt state if client started process didn't finish it.

here codepen trying test thought out.

i suggest variation of kato's rate limiting reply : http://stackoverflow.com/a/24841859/75644

data:

{ "comments": { "-jylv8kqgkuk18-nnyhk": { "content": "this first comment." }, "-jylv8kwnlfzhlbophfo": { "content": "this reply first.", "replytocommentid": "-jylv8kqgkuk18-nnyhk" }, "-jylv8kbt63wl9sb0qvt": { "content": "this reply second.", "replytocommentid": "-jylv8kwnlfzhlbophfo" }, "-jylv8keltmbr7urk08y": { "content": "this reply first.", "replytocommentid": "-jylv8kqgkuk18-nnyhk" }, "timestamp" : 1413555509137 }, "pageviews" : { "count" : 345030, "lastts" : 1413555509137 } }

security rules:

{ "rules": { "pageviews": { ".validate": "newdata.haschildren(['count','lastts'])", "count": { ".validate": "newdata.exists() && newdata.isnumber() && newdata.val() > data.val()" }, "lastts": { // timestamp can't deleted or recreate bypass our throttle ".write": "newdata.exists()", // new value must @ to the lowest degree 500 milliseconds after lastly (no more 1 message every 5 seconds) // new value must before (it since `now` when reaches server unless seek cheat) ".validate": "newdata.isnumber() && newdata.val() === && (!data.exists() || newdata.val() > data.val()+500)" } }, "comments": { // comments can't read unless pageviews lastts value within 500 milliseconds of ".read": "root.child('pageviews').child('lastts').val() > - 501", ".write": true } } }

note : haven't tested need play around bit see if works.

also, based on sample data, didn't deal uid's. need create sure you're managing can read/write here.

firebase firebase-security

No comments:

Post a Comment