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

Include gr.Request in Authentication Function #10754

Open
1 task done
XnetLoL opened this issue Mar 7, 2025 · 1 comment
Open
1 task done

Include gr.Request in Authentication Function #10754

XnetLoL opened this issue Mar 7, 2025 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@XnetLoL
Copy link

XnetLoL commented Mar 7, 2025

  • I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.

I'm facing difficulties managing user sessions for non-deepcopy-able objects in Gradio because the gr.Request object is not available in the authenticate function. This limitation forces me to use the username as a key for session management, which raises security concerns about potential user impersonation.

Describe the solution you'd like

I would like the gr.Request object to be included in the authenticate function. This would allow me to securely manage user-specific instances without relying solely on the username. Additionally, I would appreciate clarification on whether using the username as a key is safe, assuming the username is unique.

Additional context

I am implementing a session management system similar to the session_hash dictionary described in the Gradio documentation (link). My current workaround involves using the username to store user-specific instances, but I need to ensure that an authenticated user cannot change the request.username to impersonate another user.

Here is a code example illustrating the issue:

import gradio as gr

class NonDeepCopyable:
    def __init__(self):
        from threading import Lock
        self.counter = 0
        self.lock = Lock()  # Lock objects cannot be deepcopied

    def increment(self):
        with self.lock:
            self.counter += 1
            return self.counter

# Global dictionary to store user-specific instances
instances = {}

def authenticate(username, password):
    print(f"Authenticating {username} with {password}")
    if username == password:  # Testing... authentication would use firebase in this case.
        print("Authentication successful")
        instances[username] = NonDeepCopyable()
        return True
    else:
        return False

def initialize_instance(request: gr.Request):
    if request.username in instances: # Is this safe, or can someone potentially change the request.username header?
        # instances[request.username] = NonDeepCopyable()
        return "Session initialized!"
    else:
        return "Error: Authentication failed"


def cleanup_instance(request: gr.Request):
    if request.username in instances:
        del instances[request.username]


def increment_counter(request: gr.Request):
    if request.username in instances:
        instance = instances[request.username]
        return instance.username, instance.increment()
    return "Error: Session not initialized"


with gr.Blocks() as demo:
    output = gr.Textbox(label="Status")
    username = gr.Textbox(label="Username")
    counter = gr.Number(label="Counter Value")
    increment_btn = gr.Button("Increment Counter")
    increment_btn.click(increment_counter, inputs=None, outputs=[username, counter])

    # Initialize instance when page loads
    demo.load(initialize_instance, inputs=None, outputs=output)
    # Clean up instance when page is closed/refreshed
    demo.close(cleanup_instance)

demo.launch(auth=authenticate)
@XnetLoL
Copy link
Author

XnetLoL commented Mar 7, 2025

Actually, having gr.Request included in the authenticate function wouldn't solve my problem, because the session_hash changes on every reload but the authentication does not. So I guess the only fix would be to make sure that the username is secure, or the ability to add a new var in the request (token) that we can use to identify users.

@abidlabs abidlabs added the enhancement New feature or request label Mar 7, 2025
@abidlabs abidlabs self-assigned this Mar 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants