Use cookies for authentication

[jseadragon]

Hi there,

I figured out my issue from #2. This has been tested with Firmware version WB10.B929, though given what I know now, I believe it to work with the version @eseglem is on too.

The main issue was that it seems there is a difference in how the Wattbox handles auth for admin users versus non admins. For non admins, the cookie is required otherwise requests fail with an unauthorized error.

Using the cookie as an admin and non admin seems to work fine.

[jseadragon]

Realized now that I need to base this off of your develop branch as you have some refactoring there. I'll update it accordingly. In the meantime let me know if you have any feedback @eseglem!

[eseglem]

Sorry, I have been focused on other stuff lately. I will try and play with it soon.

Couple thoughts without having done any poking yet.

• Where does the certifi requirement come from?
• Thoughts on adding an async login method and then calling the appropriate one if there is no cookie yet?
• And perhaps something where it uses the cookie if it exists otherwise revert to basic auth? Idea being it would hopefully still work with other firmware versions that way.

[jseadragon]

Sorry, I have been focused on other stuff lately. I will try and play with it soon.

No problem. I've unblocked myself and deployed all this to my own local HA, seems to be working well. I'm actually not convinced it has anything to do with the version of wattbox I am on, I believe it has everything to do with if your user's role is administrator or not. It seems that the auth implementation in the wattbox is inconsistent - if you're admin, user:pass works. If you are not, you must login and get a Bearer token.

Couple thoughts without having done any poking yet.

• Where does the certifi requirement come from?

I was running into issues getting the entire stack running on my machine. I think a root / intermediate CA must have expired and on my system things do not play nicely. I'm happy to back that out and/or put it in a separate PR if you want.

To reproduce issue caused by old certifi

To reproduce the problem on origin/develop, simply do:

python3 -m venv venv2
source venv/bin/activate
pip install poetry
poetry install

(venv2) ➜  pywattbox git:(develop) ✗ poetry install 
Installing dependencies from lock file

Package operations: 12 installs, 6 updates, 4 removals

  - Removing certifi (2023.7.22)
  - Removing cffi (1.16.0)
  - Removing idna (3.4)
  - Removing pycparser (2.21)
  - Downgrading distlib (0.3.8 -> 0.3.7): Pending...
  - Downgrading filelock (3.14.0 -> 3.13.1): Failed
  - Downgrading filelock (3.14.0 -> 3.13.1): Failed
  - Downgrading distlib (0.3.8 -> 0.3.7): Failed
  - Downgrading filelock (3.14.0 -> 3.13.1): Failed

  - Downgrading filelock (3.14.0 -> 3.13.1): Failed
  OSError
  - Downgrading filelock (3.14.0 -> 3.13.1): Failed

  - Downgrading filelock (3.14.0 -> 3.13.1): Failed
  Could not find a suitable TLS CA certificate bundle, invalid path: /Users/jseawright/work/pywattbox/venv2/lib/python3.11/site-packages/certifi/cacert.pem

Ultimately this is the final set of errors I get.

• Thoughts on adding an async login method and then calling the appropriate one if there is no cookie yet?

That makes sense.

• And perhaps something where it uses the cookie if it exists otherwise revert to basic auth? Idea being it would hopefully still work with other firmware versions that way.

I'm not sure if this is necessary (See first paragraph); maybe you can test against your version of wattbox when you have some time? Otherwise, that's an easy change.