fluree / core

Fluree releases and public bug reports
0 stars 0 forks source link

Issues with `opts: { role, did }` #61

Closed aaj3f closed 7 months ago

aaj3f commented 7 months ago

Description

There are two bugs that appear to exist currently when using opts: { role, did } to issue a query/txn as a particular role and/or did

  1. role seems to only expand the IRI of a provided role via defaultContext

Since we aren't using defaultContext any longer, if I provide the following query, this is a problem, as I would want ex:yetiRole to expand to http://example.org/yetiRole and yet it is not being expanded

{
    "@context": {
        "ex": "http://example.org/"
    },
    ...
    "opts": {
        "role": "ex:yetiRole"
    }
}

However, if I simply provide the expanded IRI, then it works fine

{
    ...
    "opts": {
        "role": "http://example.org/yetiRole"
    }
}
  1. It appears that Fluree is identifying a did provided by opts: { did } correctly, however policies that leverage f:equals + f:$identity are not currently working as expected

For example, I have the following (1) Policy data, (2) User data, (3) Query as that user (and results) Add policy data

{
    "@context": {
        "ex": "http://example.org/",
        "schema": "http://schema.org/",
        "f": "https://ns.flur.ee/ledger#"
    },
    "ledger": "cookbook/base",
    "insert": {
        "@id": "ex:yetiPolicy",
        "@type": ["f:Policy"],
        "f:targetClass": {"@id" : "ex:Yeti"},
        "f:allow": [
            {
                "@id": "ex:yetiViewAllow",
                "f:targetRole": {"@id" : "ex:yetiRole"},
                "f:action": [{"@id" : "f:view"}]
            }
        ],
        "f:property": [
            {
                "@id": "ex:yetisViewOnlyOwnAge",
                "f:path": {"@id" : "schema:age"},
                "f:allow": [
                    {
                    "@id": "ex:ageViewRule",
                    "f:targetRole": {"@id" : "ex:yetiRole"},
                    "f:action": [{"@id" : "f:view"}],
                    "f:equals": { "@list": [{"@id" : "f:$identity"}, {"@id" : "ex:user"}] }
                    }
                ]
            }
        ]
    }
}

Add user with ex:yetiRole

{
    "@context": {
        "ex": "http://example.org/",
        "schema": "http://schema.org/",
        "f": "https://ns.flur.ee/ledger#"
    },
    "ledger": "cookbook/base",
    "insert": {
        "@id": "did:fluree:Tf5M4L7SNkziB4Q5gC8Hjuqu9WQKCwKpU1Y",
        "ex:user": {"@id": "ex:freddy"},
        "f:role": {
            "@id": "ex:yetiRole"
        }
    }
}

Query as user's did

{
    "@context": {
        "schema": "http://schema.org/"
    },
    "from": "cookbook/base",
    "where": {
        "@id": "?s",
        "schema:name": "?name"
    },
    "select": {
        "?s": ["*"]
    },
    "opts": {
        "did": "did:fluree:Tf5M4L7SNkziB4Q5gC8Hjuqu9WQKCwKpU1Y"
    }
}

This SHOULD return, for freddy himself, his schema:age, given the f:equals + f:$identity on schema:age, but it doesn't (although it did used to do that) Query results

[
    {
        "@id": "http://example.org/betty",
        "@type": "http://example.org/Yeti",
        "schema:name": "Betty",
        "schema:follows": {
            "@id": "http://example.org/freddy"
        }
    },
    {
        "@id": "http://example.org/freddy",
        "@type": "http://example.org/Yeti",
        "schema:name": "Freddy",
        "http://example.org/verified": true
    },
    {
        "@id": "http://example.org/letty",
        "@type": "http://example.org/Yeti",
        "schema:name": "Leticia",
        "http://example.org/nickname": "Letty",
        "schema:follows": {
            "@id": "http://example.org/freddy"
        }
    }
]
mpoffald commented 7 months ago

I have a PR for the expansion portion here: https://github.com/fluree/db/pull/693

As for the second f:$identity enforcement issue, I do not have a fix yet but have discovered a few things:

aaj3f commented 7 months ago

@mpoffald -- I mentioned this to you directly but just to track here, at least in server's implementation of your db PR (fluree/db#693), I'm still unfortunately not seeing opts: { role } working with compact, expanded, or "naive" IRIs (by "naive" I mean IRIs named like "@id": "rootRole").

Because I didn't mention this as a test case in the ticket above (I only realized it was being used by Nexus after your PR landed), I did just want to explicitly call out that we do want to make sure that if a user names a role (e.g. via f:targetRole: X) with a naive IRI like rootRole (instead of http://example.org/rootRole) that opts: { role } will still work with those naive IRIs

aaj3f commented 7 months ago

@mpoffald -- I mentioned this to you directly but just to track here, at least in server's implementation of your db PR (https://github.com/fluree/db/pull/693), I'm still unfortunately not seeing opts: { role } working with compact, expanded, or "naive" IRIs (by "naive" I mean IRIs named like "@id": "rootRole").

Because I didn't mention this as a test case in the ticket above (I only realized it was being used by Nexus after your PR landed), I did just want to explicitly call out that we do want to make sure that if a user names a role (e.g. via f:targetRole: X) with a naive IRI like rootRole (instead of http://example.org/rootRole) that opts: { role } will still work with those naive IRIs

After investigation w/ @mpoffald, we discovered that, in fact, her work to enable opts: { role } with compact (and even "naive") IRIs is working fine. The real issue there is now captured by fluree/core#65

aaj3f commented 7 months ago

@mpoffald -- the buggy behavior with f:$identity also seems to have been solved, by your PR on this issue or possibly by @dpetran's work to fix issues re: @type with policy enforcement

I was going to make a separate issue for that, but no longer any need to do so

aaj3f commented 7 months ago

Closed by fluree/db#693