DominikDoom/a1111-sd-webui-tagcomplete

Fork 0

mirror of https://github.com/DominikDoom/a1111-sd-webui-tagcomplete.git synced 2026-11-05 00:17:25 +00:00

[GH-ISSUE #188] Error - pathing on server #133

New issue

Closed

opened 2026-10-30 21:19:51 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-10-30 21:19:51 +00:00

Owner

Originally created by @HarrisTerry on GitHub (Jun 15, 2023).
Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/188

This was reported from our tech guy Vlad on integration into Vlad1111 when using on our server, wondering if you can help!

Quote - It checks its path, but doesn't compare against data-dir, so it refuses to load. extension should not check its paths, there is a built-in variable that extension should use

ValueError: '/mnt/sdnext-shared/data-dir/extensions/a1111-sd-webui-tagcomplete/tags' is not in the subpath of '/home/hello@moodmagic.ai/sdnext' OR one path is relative and the other is absolute.

Originally created by @HarrisTerry on GitHub (Jun 15, 2023). Original GitHub issue: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/issues/188 This was reported from our tech guy Vlad on integration into Vlad1111 when using on our server, wondering if you can help! Quote - It checks its path, but doesn't compare against data-dir, so it refuses to load. extension should not check its paths, there is a built-in variable that extension should use ValueError: '/mnt/sdnext-shared/data-dir/extensions/a1111-sd-webui-tagcomplete/tags' is not in the subpath of '/home/hello@moodmagic.ai/sdnext' OR one path is relative and the other is absolute.

bsakaguchi closed this issue

2026-10-30 21:19:52 +00:00

bsakaguchi commented

2026-10-30 21:19:53 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jun 15, 2023):

I am using both the built-in extension dir and script base path variables supplied by the webui. The issue is rather that the extension doesn't work with a data dir outside of the webui root, since Gradio blocks JavaScript from accessing files if they aren't in that subpath. The error above is a side effect of this line: github.com/DominikDoom/a1111-sd-webui-tagcomplete@5cbb9cefc2/scripts/tag_autocomplete_helper.py (L195)
where it writes its path to a temporary file (since file dir is the webui root instead of data dir), but even if I would use DATA_DIR instead of FILE_DIR there, it would not work on the client side due to the Gradio limits.

Sadly, there is nothing I can do about that with the way the script currently works. It is very reliant on temporary files that get created by the helper script. It might be possible to use proper custom API endpoints instead, but I currently don't have enough time to toy around with that idea, as it will require some substantial rewrites. So it might take a while until I can take a proper stab at it.

@DominikDoom commented on GitHub (Jun 15, 2023): I am using both the built-in extension dir and script base path variables supplied by the webui. The issue is rather that the extension doesn't work with a data dir outside of the webui root, since Gradio blocks JavaScript from accessing files if they aren't in that subpath. The error above is a side effect of this line: https://github.com/DominikDoom/a1111-sd-webui-tagcomplete/blob/5cbb9cefc256913d3f49801998556f784e23e243/scripts/tag_autocomplete_helper.py#L195 where it writes its path to a temporary file (since file dir is the webui root instead of data dir), but even if I would use DATA_DIR instead of FILE_DIR there, it would not work on the client side due to the Gradio limits. Sadly, there is nothing I can do about that with the way the script currently works. It is very reliant on temporary files that get created by the helper script. It might be possible to use proper custom API endpoints instead, but I currently don't have enough time to toy around with that idea, as it will require some substantial rewrites. So it might take a while until I can take a proper stab at it.

bsakaguchi commented

2026-10-30 21:19:53 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jun 15, 2023):

One thing I just found:
It seems Gradio has added an allowed_paths option in the meantime since I last had a look at it.
It might be possible to make it work using that, the webui also exposes it as a command line argument.
I'll try it out later, and if it works, will adjust the helper script accordingly.

@DominikDoom commented on GitHub (Jun 15, 2023): One thing I just found: It seems Gradio has added an allowed_paths option in the meantime since I last had a look at it. It might be possible to make it work using that, the webui also exposes it as a command line argument. I'll try it out later, and if it works, will adjust the helper script accordingly.

bsakaguchi commented

2026-10-30 21:19:53 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jun 15, 2023):

I have indeed been able to get it working with this.

You will need to add the --gradio-allowed-path argument to your webui start script to make this work, else the helper will not throw the error anymore but the server will still return 403 Unauthorized for any javascript file or tags file it tries to load.

Since you said you run a server, I can't stress this enough:
The allowed path will be public. A simple JavaScript fetch("file=path/to/file") can access any file contents in that directory and its subdirectories, as long as the filename is known. You need to be careful what you allow in there.
I suggest only allowing the install dir of tag autocomplete itself for base functionality, or if you use wildcard extensions and want to use the wildcard completion feature, the whole extensions dir at most.

@DominikDoom commented on GitHub (Jun 15, 2023): I have indeed been able to get it working with this. You will need to add the `--gradio-allowed-path` argument to your webui start script to make this work, else the helper will not throw the error anymore but the server will still return 403 Unauthorized for any javascript file or tags file it tries to load. Since you said you run a server, I can't stress this enough: The allowed path will be <ins>**public**</ins>. A simple JavaScript `fetch("file=path/to/file")` can access any file contents in that directory and its subdirectories, as long as the filename is known. You need to be careful what you allow in there. I suggest only allowing the install dir of tag autocomplete itself for base functionality, or if you use wildcard extensions and want to use the wildcard completion feature, the whole extensions dir at most.

bsakaguchi commented

2026-10-30 21:19:53 +00:00

Author

Owner

@HarrisTerry commented on GitHub (Jun 15, 2023):

Thank you so much!

@HarrisTerry commented on GitHub (Jun 15, 2023): Thank you so much!

bsakaguchi commented

2026-10-30 21:19:53 +00:00

Author

Owner

@vladmandic commented on GitHub (Jun 15, 2023):

@DominikDoom all this is true, but its a servers responsibility, not extensions - this extension is in the same situation as any other extension that includes custom html/css/js.

and i've been correctly handling user-specified data-dir in my repo for a while now - this is the only extension with this specific approach and thus was causing extension specific issue.

@vladmandic commented on GitHub (Jun 15, 2023): @DominikDoom all this is true, but its a servers responsibility, not extensions - this extension is in the same situation as any other extension that includes custom html/css/js. and i've been correctly handling user-specified data-dir in my repo for a while now - this is the only extension with this specific approach and thus was causing extension specific issue.

bsakaguchi commented

2026-10-30 21:19:54 +00:00

Author

Owner

@DominikDoom commented on GitHub (Jun 15, 2023):

@vladmandic that is true, but in the default webui it won't even load the extension's Javascript itself without this allowed paths workaround. Which is why it was never a priority until I found out about this option. More than that, I actually preferred it to error out in the terminal instead of just the browser console, since it is easier to see for most users. Instead of just getting a "not working" and having to probe myself.

The extension itself also is in a pretty unique position due to it being so old (or rather, me still trying to support old webui versions). The temp files are definitely technical debt at this point, but until I can rework it, it will have to suffice.

@DominikDoom commented on GitHub (Jun 15, 2023): @vladmandic that is true, but in the default webui it won't even load the extension's Javascript itself without this allowed paths workaround. Which is why it was never a priority until I found out about this option. More than that, I actually preferred it to error out in the terminal instead of just the browser console, since it is easier to see for most users. Instead of just getting a "not working" and having to probe myself. The extension itself also is in a pretty unique position due to it being so old (or rather, me still trying to support old webui versions). The temp files are definitely technical debt at this point, but until I can rework it, it will have to suffice.