Sounds familiar, sort of the second part of the reset reqest here: #6282

Oh, sorry, typing fast.. :-)

Oh authentification is here already. https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Command-Line-Arguments-and-Settings#command-line-arguments

Yes, but this is flat auth (all at same access level, no restriction to Settings), and it doesn't do the compartmentalizing I was mentioning above, just auths to the app.

Likely using FastAPI for bidirectional. It is actually documented just below "Authentication" above.

Using the auth hooks provided, it should be trivial to do the rest... NEAT

Annnnd Authentication!

https://gradio.app/sharing_your_app/#authentication

Found the Queueing implimentation:

https://gradio.app/setting_up_a_demo_for_maximum_performance/#enabling-gradios-queueing-system (literally JUST found it, copied and pasted here, checking it out now).

Yahtzee!

Ah, nice, so Gradio generates the routes, UI, and Rest API, all from Python. Brilliant! That means the documentation is all in one spot... ;-)

Ah, all front-end, you say... Good to know, that actually kind of helps, in a way...

The USER (in-so-far as the WebUI is concerned) shouldn't set their own path. WRT users in my enhancement, I am referring to WebUI users (logging in to the web front end). To clarify...

Bigger picture:

1. Session handler added.
2. (optional) User Management

• Authentication component added to accept usernames and passwords, and set Session information accordingly.
• Users are either hard-coded via YAML file, or SQLite DB (more involved, let's start with YAML).

4. "Admin" can set paths as currently able, additionally have full access to settings.
5. Users other than Admin (this includes un-authenticated users, which encompasses 'not' adding formal User Management), ONLY have access to Settings added to Quick Settings, etc (promoted from the Settings page).
6. WRT file save paths: the base path that is set in Settings is used, and the system adds either the Session UUID, OR the Username (when Authentication is possible). Thus limiting the viewing of images to just your images.

Ok, I didn't want to get too much more involved. Yes, there are a LOT of other considerations:

• Converting "Batches" to some form of "Job Queue"
• Each User/Session can only have one "Job"
• Interleaving processing of Job Items between Users/Sessions
• I would have to look in to how things are currently processed, but I imagine there would have to be come converting to how user scripts execute (to allow, say, for X/Y Grid to have it's overall "Job," but each task is a single render).
• Switching between Job Contexts during Interleaving.
• MUCH more, I am sure...

The Jobs thing is kind of the "big wrench," but it also brings a lot to the table:

• Currently, the Web UI can get into a state where the render HAS stopped, but the UI is not unlocking it's self.
• Additionally, it is possible to have a render executing, and clock around, and LOSE CONTROL of the render (can't view it's progress, can't stop it).
• OR, accidental F5.

Having a Job Queue of some kind could alleviate all of that.

Again, I quite literally haven't looked at a line of code yet, for all I know this is neigh impossible, but something to think about.

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

For file-view URI's, omit the obvious... ;-)

I have a couple of other "things" I want to suggest/take a look at in the coming time, and this actually kind of sets the stage in a few ways.

When loading a rendered image, the path takes the form of {host}(:{port})/file={full_file_path}, the full_file_path includes everything from system root, up to the webui root, and subsequently images directory. This is not only redundant, but also a security concern, as anyone who has access to the WebUI can gain knowledge into the layout of the underlying file system.

There is a LOT there that is identical to each file, and therefore unnecessary. Additionally, most of that path is already known by the backend, so passing it from user-space is unnecessary.

As such, I propose the following:

Proposed workflow

1. Re-structure the URI and subsequent back-end processing to take a hint and relative file path.
   Eg: 127.0.0.1:7860/file=Q:/stable-diffusion-webui/outputs/img2img/file.png Becomes: 127.0.0.1:7860/file=img2img/file.png
2. The server sees img2img and auto-fills the remainder (if it sees a hint that does NOT exist, it fails).
3. Back-end verification of ownership and location can continue as it currently does (I did check for directory traversal, and was encouraged to see that that was prevented).

Additional information

Side-effect for a future date:

This would allow for instancing of image dirs, ie: If there is a user mechanism in the future, the path img2img/file.png leaks no information, and the backend can auto-expand it to an img2img sub-directory such as Q:/stable-diffusion-webui/outputs/img2img/{username}/file.png and validate accordingly, allowing for some cross-user privacy. (this is actually my primary request, but, baby-steps)

This looks like a purely JS issue, any one-shot guidance as to where to go to edit this? I'll make a PR.

Scanning a friends embeddings directory and had this pop up a bit. We just pulled the embeddings that failed, and are assuming they are compromised until we find out otherwise.

Thoughts?

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

I would like a button in Img2Img (as well as inpainting, perhaps this moreso) to reset the output dimensions to the dimensions of the Source Image. I don't always actually want to scale/crop the image in these UIs, and this would make that simpler (at this time, if I much with anything, I have to go back and inspect the original image to sort it all out).

An additional component to this feature that would be handy would be a "Lock Aspect Ratio" checkbox. The behaviour of which would be such that updating one dimension would automatically update the other to maintain the aspect ratio.

Proposed workflow

Programmatically: On focus of either dimension fields check if "Preserve Aspect Ratio" is checked, if so, calculate current aspect ration and bind a handler to field update to update the opposite field, if not, debind handler of bound, do nothing.

The Reload Source Dimensions button should bypass the update handler.

Additional information

No response