You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 25, 2022. It is now read-only.
When running in non-packed mode (e.g. through normal go build), the idea is (AFAIU) that the directory passed to to packr.New() is used to serve files from. However, it seems that the global default resolve also allows serving files from the working directory).
So, I would expect the first Open call to succeed for the file inside the box, and the other three to fail. However, the actual output looks like this:
As you can see, only the last call (to the actually nonexistent file) returns an error, while the second and third are resolved relative to the working directory rather than the box directory.
Note that I added a little debug information. After these lines
Also note that some debug output is missing, since all the parser initialization happens before I set the loglevel.
As you can see, the Disk::Resolve function is called twice. Both times the root directory seems bogus (referring to the directory, not the box), but the second time the name parameter is already a full path (meaning that Disk::Resolve does not really have anything useful to do).
This seems to stem from the Box::Resolve function, which does this:
Essentially, it always tries to use the resolver.DefaultResolver first (also the box' defaultResolver, but that's not set here). The default resolve is defined as:
IOW, it looks in the current directory the first time it is called, and ignores its root directory when it is called for the second time.
All this seems confusing to me: I would expect such a box to have its own disk resolver with a proper root path. I also wonder what the point of a global default resolver is. Resolving files in the current directory sounds like a potential security issue. Finally, I wonder why Box::Resolve does this fallback to the box' ResolutionDir, since that sounds like a task for the resolver rather than this function.
It could be that the actual problem is that I have boxes without a defaultResolver of their own, in which case the parsing might be at fault (but even then, the code pointed above makes no sense to me, and if some of it is not meant to be used, it should probably be removed?).
The text was updated successfully, but these errors were encountered:
I have two versions of test.html, the "right one" in app/ and the "wrong one" packr-app/.
Running go run . in packr-app/ and opening http://localhost:8080/test.html gets me the wrong one, which is a little unexpected.
After executing packr2 in packr-app, running again go run . and opening http://localhost:8080/test.html now gets me the right one, which is what I expected.
When running in non-packed mode (e.g. through normal
go build
), the idea is (AFAIU) that the directory passed to topackr.New()
is used to serve files from. However, it seems that the global default resolve also allows serving files from the working directory).Best illustrated by an example:
My file tree looks like this:
So, I would expect the first
Open
call to succeed for the file inside the box, and the other three to fail. However, the actual output looks like this:As you can see, only the last call (to the actually nonexistent file) returns an error, while the second and third are resolved relative to the working directory rather than the box directory.
Note that I added a little debug information. After these lines
packr/v2/file/resolver/disk.go
Lines 25 to 29 in cef464b
I added this line:
Also note that some debug output is missing, since all the parser initialization happens before I set the loglevel.
As you can see, the
Disk::Resolve
function is called twice. Both times the root directory seems bogus (referring to the directory, not the box), but the second time thename
parameter is already a full path (meaning thatDisk::Resolve
does not really have anything useful to do).This seems to stem from the
Box::Resolve
function, which does this:https://github.com/gobuffalo/packr/blob/v2.1.0/v2/box.go#L196-L220
Essentially, it always tries to use the
resolver.DefaultResolver
first (also the box' defaultResolver, but that's not set here). The default resolve is defined as:packr/v2/file/resolver/resolver.go
Lines 15 to 20 in cef464b
IOW, it looks in the current directory the first time it is called, and ignores its root directory when it is called for the second time.
All this seems confusing to me: I would expect such a box to have its own disk resolver with a proper root path. I also wonder what the point of a global default resolver is. Resolving files in the current directory sounds like a potential security issue. Finally, I wonder why
Box::Resolve
does this fallback to the box' ResolutionDir, since that sounds like a task for the resolver rather than this function.It could be that the actual problem is that I have boxes without a
defaultResolver
of their own, in which case the parsing might be at fault (but even then, the code pointed above makes no sense to me, and if some of it is not meant to be used, it should probably be removed?).The text was updated successfully, but these errors were encountered: