Is there a way to only allow (but not require) keys in a Firebase object? I know you can use .validate to ensure that an object has certain keys. Is it possible to only allow certain keys, in a whitelist of sorts? If not, it seems like this would be a great way for unwanted/unnecessary data to make it into the database from malicious clients.
You can use Firebase's $ variables to disallow all non-specified children. From the Firebase guide on securing your data, comes this example:
{
"rules": {
"widget": {
// a widget can have a title or color attribute
"title": { ".validate": true },
"color": { ".validate": true },
// but no other child paths are allowed
// in this case, $other means any key excluding "title" and "color"
"$other": { ".validate": false }
}
}
}
So the widget node can have a color and/or a title property. But if it has any other properties, it will be rejected.
So these are all valid according to these security rules:
ref.child('widget').set({ title: 'all is blue' });
ref.child('widget').set({ color: 'blue' });
ref.child('widget').set({ title: 'all is blue', color: 'blue' });
But these are invalid according to the rules above:
ref.child('widget').set({ titel: 'all is blue' });
ref.child('widget').set({ title: 'all is blue', description: 'more...' });
Related
Using Firestore Security rules, I was wondering if there is anyway to directly view a parent document using path? For example, for any path in a subcollection, I would want to do the following:
match /myRootCollection/{myRootDoc=**} {
allow write: if request.path.split('/')[0] === "myRootDoc1":
}
I understand I can also just have the reference of myRootDoc1 in the subcollection's documents as so:
{
myRootCollection: {
{myRootDoc1}: {
mySubCollection: {
{mySubCollectionDoc1}: {
name: "someUser0",
parent: "myRootDoc1",
},
{mySubCollectionDoc2}: {
name: "someUser1",
parent: "myRootDoc1",
},
{mySubCollectionDoc3}: {
name: "someUser2",
parent: "myRootDoc1",
},
}
{myRootDoc2}: {
mySubCollection: {
{mySubCollectionDoc1}: {
name: "someUser3",
parent: "myRootDoc2",
},
{mySubCollectionDoc2}: {
name: "someUser4",
parent: "myRootDoc2",
},
{mySubCollectionDoc3}: {
name: "someUser5",
parent: "myRootDoc2",
},
}
}
}
}
Here, I would be able to read the mySubCollectionDocs if they are under a specific parent. The above works because I have the field directly in each doc, but is it possible to just read a mySubCollectionDoc and get its parent using path from Firestore Security without the specified field?
If I am able to, how would I able to query using node.js (as Firebase protects against any potential leaky queries)?
Thanks in advance.
Try this:
match /myRootCollection/{myRootDoc}/mySubCollection/{id} {
allow write: if myRootDoc == "xxx";
}
I have a key in dynamo that has two Global Secondary Indexes with different range keys. Like this:
const productSchema = new Schema(
{
productCategory: {
type: String,
index: [{
global: true,
rangeKey: 'serialNumberEnd',
name: 'productCategory',
throughput: { read: 1, write: 1 },
project: ['quantity'],
},
{
global: true,
rangeKey: 'orderType',
name: 'openOrders',
throughput: { read: 1, write: 1 },
project: true,
}],
},
{
throughput: { read: 1, write: 1 },
useNativeBooleans: true,
saveUnknown: true,
},
);`
Trying to use the 'name' does not seem to be the answer.
Resource.query('openOrder').eq(id)
How am I supposed to distinguish between the two GSI's on the same Key in a resource when constructing a query?
EDIT - Added additional context to the schema, moved answer to the answer section
In this case you don't want to be using the name property of the index. You want to be using the actual property to do this.
For example:
Resource.query('openOrder').eq(id)
.where('serialNumberEnd').lt(5)
I don't know your entire schema so it's not an exact match of what you want to do. But something like that should work.
You can also look at this test in the source code for an example of using multiple indexes on one property and querying.
const result = await Product.query(
{
hash: { productCategory: { eq: 'tags' } },
range: { orderType: { eq: 'sale' } },
},
{ indexName: 'openOrders' },).exec();
I was a bit slow at getting to this syntax. Hope this helps someone else.
EDIT: A little cleaner syntax/more context to the schema
const result = await Product.query('productCategory', { indexName: 'openOrders' }).eq('tags')
.where('orderType').eq('purchase')
.exec();
I had no luck getting Dynamoose to recognize the correct index based on the Range found in a 'where' statement. The { indexName: 'value' } is needed.
I´m learning FireBase and now at Using $ Variables to Capture Path Segments
' I read about the wildcard usage. I see they use this $othervariable.
Where is a list documentation of all variables that FireBase uses in the RealTime Databas Rules?
There is no $other variable. It's a placeholder and could be any string like $someOtherPath, or $dudesPath or $coolPath
From the docs:
{
"rules": {
"widget": {
// a widget can have a title or color attribute
"title": { ".validate": true },
"color": { ".validate": true },
// but no other child paths are allowed
// in this case, $other means any key excluding "title" and "color"
"$other": { ".validate": false }
}
}
}
The 'title' and 'color' paths are accounted for and have rules set.
$other is any path other than title or color. It could easily be
"$anyPathOtherThanTitleOrColor": { ".validate": false }
I'm working on setting up validaton rules for a Firebase data structure, created using the Bolt compiler.
I'm currently having the Bolt statement below:
path /sharedEvents/{share} is Boolean[] {
read() { isMailOfCurrentUser( share ) }
create() { isOwnerOfEvent( ...) } //NOT YET CORRECT!
delete() { isOwnerOfEvent( prior(...) } //NOT YET CORRECT!
}
With this, I'm trying to achieve that:
Only users having a mail corresponding to the key of 'share' are allowed to read the data (they use this date to retrieve the key of events shared with them.
Only the owner of an event is able to add/remove the key for his event to the list of shared events.
This second point is where I'm running into trouble -I'm not able to create the create/delete rules- since I have no idea how to reference the keys of the boolean values in the validation rule...
Example data in Firebase for the above bolt statement:
sharedEvents
ZW5kc3dhc0BldmVyeW1hMWwuYml6
-BDKBEvy-hssDhKqVF5w: true
-FDKBEvy-hsDsgsdsf5w: true
-ADBEvy-hfsdsdKqVF5w: true
aXQnc251bWJlcnNAbWExbDJ1LnVz
-KBEvy-hsDhH6OKqVF5w: true
To clarify the needs on this example:
Only user with mail 'ZW5kc3dhc0BldmVyeW1hMWwuYml6' is able to read the three nested childs.
Only the owner of event '-BDKBEvy-hssDhKqVF5w' should be able to create/delete this value. (the same for the other event key/boolean pairs).
My question: is this setup going to work (and how to setup the create/delete rules)? Or is this not going to work and should I rethink/structure the data?
Any help is appreciated!
-----------------OUTPUT JSON FILE------------------------------------------
The question above has been answered, this section is showing the resulting json
"sharedEvents": {
"$share": {
".read": "<removed for readability>",
"$event": {
".validate": "newData.isBoolean()",
".write": "<removed for readability>"
}
}
},
Thanks again for your quick support!
You'll need a nested path statement to handle the restriction on the events (the nodes under /sharedEvents/$mail/$eventid). I quickly prototyped with this JSON structure:
{
"events": {
"-ADBEvy-hfsdsdKqVF5w": {
"name": "Event 1",
"ownerMail": "aXQnc251bWJlcnNAbWExbDJ1LnVz"
},
"-BDKBEvy-hssDhKqVF5w": {
"name": "Event 2",
"ownerMail": "aXQnc251bWJlcnNAbWExbDJ1LnVz"
},
"-FDKBEvy-hsDsgsdsf5w": {
"name": "Event 3",
"ownerMail": "aXQnc251bWJlcnNAbWExbDJ1LnVz"
},
"-KBEvy-hsDhH6OKqVF5w": {
"name": "Event 3",
"ownerMail": "ZW5kc3dhc0BldmVyeW1hMWwuYml6"
}
},
"sharedEvents": {
"ZW5kc3dhc0BldmVyeW1hMWwuYml6": {
"-ADBEvy-hfsdsdKqVF5w": true,
"-BDKBEvy-hssDhKqVF5w": true,
"-FDKBEvy-hsDsgsdsf5w": true
},
"aXQnc251bWJlcnNAbWExbDJ1LnVz": {
"-KBEvy-hsDhH6OKqVF5w": true
}
},
"userMails": {
"peter": "aXQnc251bWJlcnNAbWExbDJ1LnVz",
"puf": "ZW5kc3dhc0BldmVyeW1hMWwuYml6"
}
}
And came up with these rules:
path /sharedEvents/{share} {
read() { isMailOfCurrentUser(share) }
}
path /sharedEvents/{share}/{event} is Boolean {
create() { isOwnerOfEvent(event) }
delete() { isOwnerOfEvent(prior(event)) }
}
isMailOfCurrentUser(share) { true }
getMailOfCurrentUser(uid) { root.ownerMails.uid }
getEventOwnerMail(event) { root.events.event.ownerMail }
isOwnerOfEvent(event) { getMailOfCurrentUser(auth.uid) == getEventOwnerMail(event) }
Ignoring any mistakes on my end, this should be the basics of the authorization structure you're looking for.
I'm having an issue setting up roles in my project that uses meteor-collection2. I assume this is the roles package noted in the collection2 docs.
I'm using accounts-password and ian:accounts-ui-bootstrap-3 as my accounts solution. Here's my config for it:
Accounts.ui.config({
requestPermissions: {},
extraSignupFields: [{
fieldName: 'first-name',
fieldLabel: 'First name',
inputType: 'text',
visible: true,
validate: function(value, errorFunction) {
if (!value) {
errorFunction("Please write your first name");
return false;
} else {
return true;
}
}
}, {
fieldName: 'last-name',
fieldLabel: 'Last name',
inputType: 'text',
visible: true,
}, {
fieldName: 'terms',
fieldLabel: 'I accept the terms and conditions',
inputType: 'checkbox',
visible: true,
saveToProfile: false,
validate: function(value, errorFunction) {
if (value) {
return true;
} else {
errorFunction('You must accept the terms and conditions.');
return false;
}
}
}]
});
I added the roles field to my Users Schema:
Schemas.User = new SimpleSchema({
username: {
type: String,
// For accounts-password, either emails or username is required, but not both. It is OK to make this
// optional here because the accounts-password package does its own validation.
// Third-party login packages may not require either. Adjust this schema as necessary for your usage.
optional: true
},
emails: {
type: [Object],
optional: true
},
"emails.$.address": {
type: String,
regEx: SimpleSchema.RegEx.Email
},
"emails.$.verified": {
type: Boolean
},
createdAt: {
type: Date
},
services: {
type: Object,
optional: true,
blackbox: true
},
profile: {
type: Object,
optional: true,
blackbox: true
},
"first-name": {
type: String
},
"last-name": {
type: String
},
// Add `roles` to your schema if you use the meteor-roles package.
// Option 1: Object type
// If you specify that type as Object, you must also specify the
// `Roles.GLOBAL_GROUP` group whenever you add a user to a role.
// Example:
// Roles.addUsersToRoles(userId, ["admin"], Roles.GLOBAL_GROUP);
// You can't mix and match adding with and without a group since
// you will fail validation in some cases.
roles: {
type: Object,
optional: true,
blackbox: true
}
});
And now I want to immediately create one user on the first time I run my project with an admin role and stop any others from being created afterwards:
/*----------------------------------------------- #2 Create admin user ----------------------------------------------*/
/*Notes: Create an admin-type user if no users exist yet.*/
if (Meteor.users.find().count() === 0) { /*------------------------------------ If there are no users created yet*/
var users = [{
username: "admin",
name: "admin",
email: "test#test.com",
roles: ['admin']
}];
_.each(users, function(user) {
var id = Accounts.createUser({
username: user.username,
email: user.email,
password: "mypassword123",
profile: {
name: user.name
},
first-name: Me,
last-name: MeName
});
if (user.roles.length > 0) {
// Need _id of existing user record so this call must come
// after `Accounts.createUser` or `Accounts.onCreate`
Roles.addUsersToRoles(id, user.roles);
}
});
}
/*-------------------------------------------------------------------------------------------------------------------*/
/*Prevent non-authorized users from creating new users*/
Accounts.validateNewUser(function(user) {
var loggedInUser = Meteor.user();
if (Roles.userIsInRole(loggedInUser, ['admin'])) {
return true;
}
throw new Meteor.Error(403, "Not authorized to create new users");
});
So far apparently so good: I get the new user.
The problem is when I use spacebars to hide admin features in html the created user isn't recognized as an admin and they are hidden from me...
{{#if isInRole 'admin'}}
<p>Exclusive to admin stuff</p>
{{/if}}
If using Roles as an Object (option #1) you must specify a group and permission for all users (I believe with Roles 2.0 which is coming out soon this will no longer be the case), so for something like an admin user you could use Roles.GLOBAL_GROUP which is used to apply blanket permissions across all groups.
For this, you would need to make the follow change:
Roles.addUsersToRoles(id, user.roles);
To this:
Roles.addUsersToRoles(id, user.roles, Roles.GLOBAL_GROUP);
You will also need to specify the group inside of your isInRole helper, here's an example of how that would look:
Roles.addUsersToRoles(joesUserId, ['manage-team'], 'manchester-united.com')
//manchester-united.com is the group
For your isInRole helper on the client, you would use this:
{{#if isInRole 'manage-team' 'manchester-united.com'}}
<h3>Manage Team things go here!</h3>
{{/if}}
You are currently using it as a String (Option #2, without groups). If you are planning on using groups for any users then you will need to make the changes I explained above (you can then remove option #2 as well), but if you don't plan on using groups for any users then you can remove Option #1 and simply use it as a String.
There is a helpful tutorial on the Roles package here, and the package docs are great too.