The wildchild constraint seem to be ignored about blaze_compiler HOT 3 CLOSED

The latest blaze has optimisations, so the verbose expressions have
simplified to false for everything (note the occurrences of '&& false' in
the verbose expressions which simplify to false).

You need to grant read/write access in the access control portion, add

access:-
location: /
read: true
write: true

at the end of your yaml file

On Fri, Oct 31, 2014 at 6:34 AM, gajuro [email protected] wrote:

Given the next yaml file:

functions:

• isWorkspaceRole(userId, workspaceId, role): root['/rels/workspaces/users/' + workspaceId][userId]['role'] == role
  schema:
  properties:
  rels:
  properties:
  workspaces:
  properties:
  users:
  $workspace_id:
  constraint: isWorkspaceRole(auth.id, $workspace_id, 'administrator') ||
  isWorkspaceRole(auth.id, $workspace_id, 'collaborator') && next != null
  ~$user_id: {}

This is what gets generated with the latest three versions of blaze:

{
"rules":{
".write":"false",
".read":"false",
"rels": {
".write":"false",
".read":"false",
"workspaces": {
".write":"false",
".read":"false",
"users": {
".write":"false",
".read":"false",
"$workspace_id": {
".write":"false",
".read":"false",
"$user_id": {
".write":"false",
".validate":"false",
".read":"false"
}
}
}
}
}
}
}

This is the output of blaze 0.0.14:

{
"rules":{
".write":"true&&true&&true&&true&&false&&false",
".read":"false",
"rels": {
".write":"true&&true&&true&&false&&false",
".read":"false",
"workspaces": {
".write":"true&&true&&false&&false",
".read":"false",
"users": {
".write":"true&&false&&false",
".read":"false",
"$workspace_id": {
".write":"true&&true&&false",
".read":"false",
"$user_id": {
".write":"true&&true&&true&&true&&(root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='administrator'||root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='collaborator'&&newData.parent().val()!=null)&&true&&false",
".validate":"true&&true&&true&&true&&(root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='administrator'||root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='collaborator'&&newData.parent().val()!=null)&&true&&false",
".read":"false"
}
}
}
}
}
}
}

Am I doing something wrong? Thanks.

—
Reply to this email directly or view it on GitHub
#20.

from blaze_compiler.

Tom,

Thank for your quick answer on all issues I submitted.

After adding the access rules this is what I get:

{
  "rules":{
    ".write":"(false)",
    ".read":"true",
    "rels": {
      ".write":"(false)",
      ".read":"true",
      "workspaces": {
        ".write":"(false)",
        ".read":"true",
        "users": {
          ".write":"(false)",
          ".read":"true",
          "$workspace_id": {
            ".write":"((true))",
            ".read":"true",
            "$user_id": {
              ".write":"(((root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='administrator'||root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='collaborator'&&newData.parent().val()!=null)))",
              ".validate":"(((root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='administrator'||root.child('/rels/workspaces/users/'+$workspace_id).child(auth.id).child('role').val()=='collaborator'&&newData.parent().val()!=null)))",
              ".read":"true"
            }
          }
        }
      }
    }
  }
}

Notice the lack of constraints at the $workspace_id level. The constraints appear though if I remove the ~$user_id from the schema all together.

from blaze_compiler.

yeah that was a big since introduction of the new wildertypes, fixed. Thanks

from blaze_compiler.