chronark / envshare

Share Environnment Variables Securely
https://envshare.dev
MIT License
581 stars 60 forks source link

api #17

Closed chronark closed 1 year ago

chronark commented 1 year ago
vercel[bot] commented 1 year ago

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

Name Status Preview Comments Updated
envshare ✅ Ready (Inspect) Visit Preview 💬 Add your feedback Jan 18, 2023 at 7:23PM (UTC)
chronark commented 1 year ago

📝 Changed routes:

Commit 3355178b44af717fef35c6b77c2bcf381e1839ea (https://envshare-g6x3rqxk4-chronark.vercel.app).

chukwumaokere commented 1 year ago

Continuing our conversation from https://github.com/chronark/envshare/pull/8#issuecomment-1386245156

Great work adding Zod, I was considering it myself for this but was gonna ask your approval since its your repo haha. I was gonna manually write input validators for the POST endpoint yesterday but it was too exhausting.

Your piece about the encryption key on the server is right. I read the process you had from your tweet and it made me second guess this endpoints current behavior 🤔

The CLI could utilize the endpoint if the CLI is the "client" and has the encryption key and sends the encrypted data, yeah. The server itself shouldnt have the encryption key...

Im pulling and checking it out

chronark commented 1 year ago

Continuing our conversation from #8 (comment)

Great work adding Zod, I was considering it myself for this but was gonna ask your approval since its your repo haha. I was gonna manually write input validators for the POST endpoint yesterday but it was too exhausting.

Your piece about the encryption key on the server is right. I read the process you had from your tweet and it made me second guess this endpoints current behavior 🤔

The CLI could utilize the endpoint if the CLI is the "client" and has the encryption key and sends the encrypted data, yeah. The server itself shouldnt have the encryption key...

Im pulling and checking it out

Yes exactly the client in this case is the cli, which needs to do the encryption, so we actually might need to allow an optional field for an initialization vector or something else. Let's worry about that once we are working on the CLI part

chronark commented 1 year ago

Now its more clear these look good to me. Tested locally and working as expected with the new ttl and read headers and omitted values work as expected now. 👍🏾

Do we want to return any more additional data from the backend POST request? Just so people can verify the data they've sent in i.e., reads/expiration info?

Yeah, I'll add them and then ship this in an hour or so