Login & API keys storage

[SammyDeM]

• Possiblity to login via username and password.
• API keys saving in to account.

[enricoros]

@SammyDeM would you like this capability to be added to big-agi.com, or in the opensource code here on github?

[SammyDeM]

Yes if that is possible

Met vriendelijke groet,

Sammy DE MAERTELAERE

T +32 4 8586 7098 (tel:+32%204%208586%207098)

E @. @.)

W www.s-networks.org (http://www.s-networks.org/)

Please consider the environment before printing this email.

Sent from mobile, so excuse brevity and typos

​

On Apr 5, 2024 at 10:31 PM, <Enrico Ros @.***)> wrote:

@SammyDeM (https://github.com/SammyDeM) would you like this capability to be added to big-agi.com, or in the opensource code here on github?

— Reply to this email directly, view it on GitHub (https://github.com/enricoros/big-AGI/issues/487#issuecomment-2040587796), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ARO35VFIATHW3ZZSWXKENTTY34C35AVCNFSM6AAAAABFZFFAP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBQGU4DONZZGY). You are receiving this because you were mentioned.Message ID: @.***>

[Chammar37]

@enricoros is this something that will be included in the opensource code alongside managing user-sessions? Curious if its something we can expect

[maribox]

I'm looking for exactly this feature, but on big-AGI.com if that's possible, so I can have the same API keys on my desktop, laptop and phone

[enricoros]

Thanks @Chammar37, @maribox. For making this available on the opensource code, I'd have to introduce deployment complexities, for instance making this dependent on having a database account, or local supabase containers or similar. This will complicate the dev experience for the current people deploying it -- so I'm looking at a smart solution for persistency which doesn't introduce hurdles -- suggestions are welcome.

[maribox]

I sadly don't have anything smart to offer :D But honestly for now even a settings + APIs Import/Export feature would be better than nothing and at least create no problems for current deployments.

[shiribailem]

My suggestion: first and foremost make a url endpoint that maps to settings info, as a basic first implementation this could support a static file (say if I have a server password or otherwise private controlled access, I could use the same to automatically fill in settings for all devices), the server could use continue as-is with the defaults if it can't access that endpoint.

Then for simplest implementation of login/per-account would probably be to read the REMOTE_USER environment variable and passing that to the url call for that file? (This would skip building an authentication system and let you just use basic authentication in whatever server software you like)

Follow this with maybe implementing support for a POST call to that same URL to update it.

From there if we build just the basic structure of these two calls it can easily be made into a modular optional component, making it easier to develop different solution ideas easily without fussing extensively with the rest of the code.

My idea for how this might progress in development:

1) static config file setup - open-source deployment users can use this readily but obviously won't be on the main site 2) rudimentary per-user setup - basically something that's a quick slot in that takes the passed username, pulls a settings file from a directory under that name, merges it with a default config file, and provides it. Still geared for open-source server, probably not greatly performant for main site. 3) rudimentary post setup - basically just reverse the above so relevant settings will get written to the files on update 4) experiment with more advanced replacements that support more efficient storage and retrieval methods.

Then follow the same process for more extensive saves like if you want to save chat history/etc.