Closed dfguerrerom closed 1 month ago
Hi Daniel,
if you store in reactive variables, they are per 'user' (or kernel rather). It's up to the libraries that you use the provide that flexibility to be able to store the needed data into solara's reactive variables. Would that work for you? A bit lower level would be to use the get_kernel_id, see: https://solara.dev/documentation/examples/general/custom_storage for an example.
cheers,
Maarten
I don't think that modifying the package would be an option, I believe that they don't have considered this use case. what do you think about using the kernel_id to instantiate a worker per user and do the authentication process there, so it can receive calls from the main thread?
We could do very complicated workarounds, but I have to say I find it a bit strange that this packages does not support this.
It means that this package can also not be used in fastapi, flask, or any other webserver that supports multiple users. Do you think it makes sense to first contact the authors and explain the situation?
It is very difficult to contact them and probably a solution won't arrive on time, they are aware of that limitation for long time ago. I was digging into the code, and I think a good solution would be to store the user credentials in a reactive variable and bypass the existing API for executing requests. Instead, I will directly make HTTP requests to their REST API.
I'm closing this issue since the problem is not related with Solara anymore. I just started a new repository to overcome this earthengine-api
limitation: https://github.com/dfguerrerom/ee-session-client
I am exploring the transition from Voila to Solara for our geospatial applications to achieve better performance and scalability, however, I'm having problems related to multi-user authentication in a shared environment.
The problem: In our current setup, user credentials are stored locally, and once authenticated, the application's API stores the authentication as a global variable (see example here: https://github.com/openforis/earthengine-api/blob/dc1290b251f7064a778a7fb367d2f08c45586ddb/python/ee/data.py#L227). This results in all users sharing the same execution context, which is problematic for a scalable multi-user solution. The core issue is the lack of support for separate user contexts in multi-user environments within the application framework. This problem is not specific to a single API or service (e.g., Google Earth Engine) but maybe it is relevant to any scenario where multiple users need to authenticate and maintain individual sessions securely.
Ideally I would like to know if there's a way to support individual user contexts, ensuring each user can authenticate and maintain a separate session securely.