daniel-farina commented 9 months ago

This PR moves this project away from next-auth to supabase-auth. This makes the configuration a lot simpler.

Tasks:

[x] removed next-auth references and libraries
[x] updated db migration
[x] update .env sample
[x] update docs (might need more revisions)
[x] add login/logout
[x] add google enabled by default
[x] refactored helper
[ ] need to fix supabase clients and implement SSR https://supabase.com/blog/supabase-is-now-compatible-with-nextjs-14 https://supabase.com/docs/guides/auth/server-side/overview

Now the application works immediately once supabase is configured, you can login with magic links, no need to setup smtp providers.

Todo

The login by wildcard *@email feature has been removed, we might want to add that again

vercel[bot] commented 9 months ago

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
unsaged	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 24, 2023 9:24pm

1 Ignored Deployment

sebiweise commented 9 months ago

@daniel-farina Just one quick thought: Wouldn´t it be easier to just check if the specific AI Vendor Key is defined? Something like

if(openai_key || OPENAI_API_KEY) {
  const response = await getAvailableOpenAIModels(openai_key);
  ...
}

This way we don´t need to add another configuration variable to unsaged.

I honestly don´t see the point of the ability to disable AI vendors via ENV var, either you don´t define a Global API Key and/or Url settings or the user don´t define a key in the frontend so I think disabling the model lookup by the existence of the necessary configuration would be enough, what do you mean?

daniel-farina commented 9 months ago

@daniel-farina Just one quick thought: Wouldn´t it be easier to just check if the specific AI Vendor Key is defined? Something like
if(openai_key || OPENAI_API_KEY) {
  const response = await getAvailableOpenAIModels(openai_key);
  ...
}
This way we don´t need to add another configuration variable to unsaged.

I honestly don´t see the point of the ability to disable AI vendors via ENV var, either you don´t define a Global API Key and/or Url settings or the user don´t define a key in the frontend so I think disabling the model lookup by the existence of the necessary configuration would be enough, what do you mean?

I initially had the same thought, but then I realized that it's not foolproof. If someone merely uses a placeholder, they might not be aware that it's active, even if the key is incorrect. Therefore the app consistently attempt to fetch the models with wrong keys.

but actually I'm ok with if(openai_key || OPENAI_API_KEY) and just explaining tha adding a value will automatically activate fetching of models on the app as a note on the docs.

sebiweise commented 9 months ago

That's a point but I think everyone who is hosting undated themself will know that he has to put a valid key in it, for the user input we could implement a simple validation of a minimum length or something like that. I don't know maybe there is a regex for the validation of OpenAI API key?

daniel-farina commented 9 months ago

That's a point but I think everyone who is hosting undated themself will know that he has to put a valid key in it, for the user input we could implement a simple validation of a minimum length or something like that. I don't know maybe there is a regex for the validation of OpenAI API key?

works with me! 👍 I'll change it before we merge. I'm still troubleshooting SSR and latest version of supabase. Checkout the last commit, it should be working now. I'm just troubleshooting prod buildon vercel. Prod build works on local env for now.

jorge-menjivar / unsaged

Move from next-auth to supabase-auth (On refactored code) #105

Todo