allow api credentials through dashboard instead of env

[aryanbhosale]

As @peterdudfield had mentioned in #170
run a general api and a general dashboard. This could even be a public api / dashboard
Then the users can

1. Enter a site details(their credentials that are now in env file)
   2a. Get a forecast with no live data
   2b. Get a forecast with live data, by entering credentials for that inverter.

[Clemo97]

Hey @aryanbhosale and @peterdudfield do we want the inverter values entered by the user to persist or be temporary such that the values reset on app refresh/restart?

[aryanbhosale]

Hey @aryanbhosale and @peterdudfield do we want the inverter values entered by the user to persist or be temporary such that the values reset on app refresh/restart?

Ideally the values should persist upon refreshing the page at least, upon restart perhaps some default values could be shown

[akshayw1]

Is the issue open to work? @peterdudfield @aryanbhosale

[aryanbhosale]

Is the issue open to work? @peterdudfield @aryanbhosale

Yes, but do discuss your approach before implementation, as the credentials are private, we need to ensure that they're handled securely

[akshayw1]

@aryanbhosale The approach I’m considering is to first encrypt the user input with a cipher on the server side before saving it to the database. When we need to access the credentials, they will be decrypted on the server side and masked (e.g., "openclimatefix" → "****climatefix") before being sent to the frontend. This ensures that the credentials are never fully exposed on the client side, maintaining privacy and handling them securely, also we may used tokenization, if really needed, let me know what you think about the approach

[aryanbhosale]

@aryanbhosale The approach I’m considering is to first encrypt the user input with a cipher on the server side before saving it to the database. When we need to access the credentials, they will be decrypted on the server side and masked (e.g., "openclimatefix" → "****climatefix") before being sent to the frontend. This ensures that the credentials are never fully exposed on the client side, maintaining privacy and handling them securely, also we may used tokenization, if really needed, let me know what you think about the approach

why would we store the input to the db? we don't have user login functionality so what do we achieve by storing them? We're currently working with browser sessions and utilizing the access/refresh tokens

[akshayw1]

@aryanbhosale The approach I’m considering is to first encrypt the user input with a cipher on the server side before saving it to the database. When we need to access the credentials, they will be decrypted on the server side and masked (e.g., "openclimatefix" → "****climatefix") before being sent to the frontend. This ensures that the credentials are never fully exposed on the client side, maintaining privacy and handling them securely, also we may used tokenization, if really needed, let me know what you think about the approach

why would we store the input to the db? we don't have user login functionality so what do we achieve by storing them? We're currently working with browser sessions and utilizing the access/refresh tokens

I considered the ideal case where storing credentials securely in the db might be usful, but given that you're working with browser sessions and utilizing access/refresh tokens, it might not be necessary. Let me think it over one more time

[akshayw1]

@aryanbhosale Instead of storing credentials in a db, we can use in-memory storage for session mgment. When the user enters the API credentials, we store them temporarily in memory for the duration of their session. Once the session ends (like after a logout or session timeout), the credentials are cleared automatically. This way, we avoid persisting sensitive data, and it stays secure throughout the session. and accordingly default key etc could be also handled, Please let me know if I’m missing something.

[aryanbhosale]

@aryanbhosale Instead of storing credentials in a db, we can use in-memory storage for session mgment. When the user enters the API credentials, we store them temporarily in memory for the duration of their session. Once the session ends (like after a logout or session timeout), the credentials are cleared automatically. This way, we avoid persisting sensitive data, and it stays secure throughout the session. and accordingly default key etc could be also handled, Please let me know if I’m missing something.

yup this is right, and the session management is to be done in the backend(not the streamlit code)

[akshayw1]

ofc it would be done in backend only (not in streamlit code)

[akshayw1]

Hey! Can you let me know which keys from the env file need to be made accessible on the dashboard? I can start working on it once I have that information. Thanks! @aryanbhosale

[akshayw1]

Hey! Can you let me know which keys from the env file need to be made accessible on the dashboard? I can start working on it once I have that information. Thanks! @aryanbhosale

? @aryanbhosale

[Clemo97]

Hey! Can you let me know which keys from the env file need to be made accessible on the dashboard? I can start working on it once I have that information. Thanks! @aryanbhosale

? @aryanbhosale

Hey, I think all the variables related to an inverter i.e. (enphase), otherwise it won't work.