Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The [opa eval] command is unable to access Rego policies located on other drives on windows #6922

Closed
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion loader/loader.go
Original file line number Diff line number Diff line change
Expand Up @@ -582,7 +582,9 @@ func SplitPrefix(path string) ([]string, string) {
}
parts := strings.SplitN(path, ":", 2)
if len(parts) == 2 && len(parts[0]) > 0 {
return strings.Split(parts[0], "."), parts[1]
if strings.HasPrefix(parts[1], "file:///") || len(parts[0]) > 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we put significance on the path containing file:/// or the document prefix being more than one chars long for us to return those parts rather than the given path?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add some context: I believe the prefix part is the prefix for which the contents of that file will be found under the data document during evaluation.

E.g.: given the following data file data.json:

{
  "foo": 42
}

and we run:

$ opa eval -fpretty -d file:///path/to/my/file/data.json 'data = x'

we expect the output:

+------------+
|     x      |
+------------+
| {"foo":42} |
+------------+

But if we add the a: prefix to the file path, we expect this prefix to be added to the data document:

opa eval -fpretty -d a:file:///path/to/my/file/data.json 'data = x'
+------------------+
|        x         |
+------------------+
| {"a":{"foo":42}} |
+------------------+

return strings.Split(parts[0], "."), parts[1]
}
}
return nil, path
}
Expand Down
9 changes: 9 additions & 0 deletions loader/loader_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -879,6 +879,15 @@ func TestSplitPrefix(t *testing.T) {
wantParts: []string{"x", "y"},
wantPath: "file:///c:/a/b/c",
},
{
input: "c:/a/b/c",
wantPath: "c:/a/b/c",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem compatible with how data prefixes work in OPA, as we'd expect c to become the data prefix.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it advisable to always use a file URL(ex: file:///c:/path/to/my/file/data.json instead of c:/path/to/my/file/data.json), especially on Windows?
How does the system behave if we provide the path as c:/path/to/my/file/data.json? In this case, should c be interpreted as a prefix or as the drive letter?

In this image, we see that using c:/path/to/my/file/data.json has failed
Screenshot 2024-08-27 at 6 25 33 PM

},
{
input: "c:file:///c:/a/b/c",
wantParts: []string{"c"},
wantPath: "file:///c:/a/b/c",
},
}

for _, tc := range tests {
Expand Down