-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] redesign #13
base: master
Are you sure you want to change the base?
[WIP] redesign #13
Conversation
The goal is to make the program capable of handling concurrent events. This eliminated the need for timeouts, which wouldn't really scale for the future (we are planning to make a mobile site as an alternative interface to the system). Work in progress.
This way, we are prolonging door open time (but without stacking), instead of cancelling concurrent events. Old behavior: the door will be closed after n seconds since being opened. Events that happened while the door was open were ignored. New behavior: the door will be closed after n seconds since the last event (e.g. the last card reader event).
Bardzo pobieżnie przejrzałem kod i mam kilka ogólnych uwag: Czytając je pamiętaj, że to tylko i wyłącznie moje uwagi. Bardzo się cieszę, że ktoś chce ten projekt dalej rozwijać, a nie że za jakiś czas KSI wróci do używania klucza bo nikomu nie będzie się chciało czegoś zdebugować 😉
|
Słyszałem kiedyś, że ostatecznie chcemy mieć więcej sposobów na otwieranie zamka, np. przez appkę, stronę internetową, panel admina itd. Więc gdzieś ten interfejs HTTP będzie potrzebny. Faktycznie mamy 2 (albo więcej?) możliwości:
Chodziło mi o to, że obecny
Też mi się ten spinner nie podoba, mimo że dla RPi odpalenie czegoś 10 razy na sekundę to nic (wątpię że będzie to jakkolwiek zauważalne, na moim PC ten wątek "zużywa" wg topa 0.0% CPU, przypuszczam że na RPi będzie tak samo). Gdybym miał w Pythonie coś na wzór Rust-owego kanału mpsc, to bym zrobił kolejkę wiadomości między wątkami, każda wiadomość zawierała by timestamp. Te kanały mpsc mają możliwość zarówno blocking read, jak i non-blocking read. Wtedy wątek odblokowujący drzwi by się blokował w oczekiwaniu na wiadomość, jednocześnie przed zamknięciem drzwi robiłby non-blocking read żeby sprawdzić czy nie chcemy "przedłużać" czasu otwarcia (bo następna osoba chce wejść, bo ktoś nadal trzyma legitymację przy czytniku itd). Ale nie znam niczego takiego, gdy po 5 minutach niczego nie znalazłem to stwierdziłem że kiedy indziej można to zoptymalizować.
W tym modelu gdzie VPS wysyła polecenia po SSH do RPi - pewnie tak. W tym modelu gdzie chcemy mieć przekierowanie portów - nie wiem czy to by cokolwiek nam uprościło. Wtedy chyba potrzebowalibyśmy nginxa jako proxy (tzn i tak fajnie by było go mieć, ale w modelu z tunnelingiem nie jest niezbędny). Choć z drugiej strony gdybyśmy robili SSH tunneling, to pewnie chcielibyśmy nowego usera na VPSie dla bezpieczeństwa, z
Kiedy natywny popup z pytaniem o hasło się pojawia, nie da się odpalać menadżerów haseł działających jako rozszerzenia do przeglądarek:
Ten Za to jeśli chodzi o konta użytkowników, to faktycznie przy 8 znakowym serial number karty jest możliwy brute force, a wymiana legitymacji jest droga i czasochłonna. Nie chciałem jednak zmieniać formatu bazy danych jaki mamy (może niesłusznie, w końcu jest jeszcze ten problem z Chyba że ci chodziło o HTTP vs HTTPS. Nie wiem, jak wygląda VPS KSI, ale strona KSI stoi na HTTPSie, a komunikacja VPS - RPi szła by po Wireguard albo po SSH, więc też nie plaintextem. Tak czy inaczej, ja w najbliższej przyszłości raczej nie będę się skupiał na drzwiach otwartych, dlatego starałem się w moich wiadomościach opisać wszystkie pomysły i problemy jakie mam. Jeśli ktoś chce napisać jakiś kod, i przez to podejmie jakąś decyzję dotyczącą tego redesignu za mnie, to nie mam nic przeciwko. |
Wow, sporo tekstu - tak na szybko w keepasie możesz w ustawieniach włączyć automatyczne wypełnianie HTTP Basic Auth - u mnie działa 😉 Resztę tekstu przeczytam z większym zrozumieniem jak tylko znajdę chwilę :) |
Nareszcie uporządkowałem trochę napisany kod, więc wrzucam to co mam, żeby każdy mógł popatrzeć. To jest mój (wstępny) pomysł na nowe wnętrze projektu. Zamiast Unix socketa przyjmującego 1 połączenie na raz (i blokującego się na czas otwarcia drzwi), jest RESTowe API. Ponadto jest podział na klasy, jakieś proste testy, konfiguracja pipenv-a do zależności.
Code review w sensownej ilości mile widziany (nie jestem pythonowcem).
Do zrobienia przed zmerge'owaniem (chyba że chcemy mieć nowy branch np.
next
):superuser_password.txt
- powinno być super łatwe.unique
constraint z SQLa, jeśli nie, to dodać API do usuwania legitymacji. Obecna wersja też ma ten problem, myślę, że to dobra okazja do naprawienia tego.worker.py
będzie odpalanyserver.py
, ale fajnie by było przygotować go na wystawienie do Internetu [1] przygotowując WSGI. Przy okazji część kodu będzie można usunąć (np. dependencies oddelegować pipenv-owi). Ten task na samym końcu.[0] IMO wystarczy statyczny HTML z JSem z fetch API (bo przy logowaniu "czystym HTMLem" aka Basic Auth, przeglądarki słabo współpracują z menadżerami haseł).
[1] Co do wystawienia serwera na świat, proponuję reverse SSH tunelling. Wtedy Pi łączyłby się z VPSem, a VPS dostając połączenie np. na port 5000 przekazywałby po SSH transmisję do Pi (oczywiście prostą konfiguracją nginxa można zrobić to ładniej). Z tego co pamiętam na domyślnych ustawieniach reverse proxy binduje się tylko do interfejsu local na VPSie (czyli nasz serwis z RPi byłby dostępny na VPSie tylko z localhosta z punktu widzenia VPSa, ale nie byłby dostępny z internetu). Trzeba zmienić jakąś linię w configu sshd żeby pozwolić na bindowanie do innych interfejsów, i potem z klienta łączyć się np. tak: