WebApi m.in. dynamiczny adres IP i IPv6

Cześć,
Piszę stronę w Blazor WASM, gdzie część danych na stronie, powinna pochodzić z serwerów użytkowników za pośrednictwem innej aplikacji którą muszę w tym celu również stworzyć.
Tak więc chcę stworzyć takie WebApi, które będzie instalowane na serwerach/komputerach użytkownika i z którym będą się łączyć strony www w celu wyświetlania pewnych danych z tego komputera / sieci (temu i innym użytkownikom) - chodzi o dane z bazy danych innej aplikacji.

Moje pytania są następujące:

1. Czy da się napisać takie API z którym będą się łączyć userzy bez konieczności przekierowania portów na routerze? Nie powinien to być duży problem, ale...
2. W przypadku gdy IP użytkownika jest zmienne aplikacja będzie wysyłać np. co 1 minutę informację na główny serwer jaki jest aktualny adres IP a użytkownik w przypadku, gdy nie będzie mógł pobrać danych z podanego adresu to będzie wysyłał zapytanie o aktualizację adresu IP. Czy zmienne IP może stwarzać dodatkowe problemy przy takim rozwiązaniu?
3. Co w przypadku, gdy user ma IPv6 - czy nie będzie to problemem przy próbie połączenia się z zewnątrz? Czy HttpClient nie będzie miał z tym problemów?

Z góry dziękuję za waszą pomoc.

Skoro piszesz WebAPI to ono ma siedzieć na określonym porcie i czekać na klientów.
O ile to sieć lokalna to możesz zapomnieć o IP4/6 zwyczajnie nadajesz nazwę i łączysz się wg nazwy.
Jeżeli to nie jest sieć lokalna zaś "klienci" są za maskardą to nie powinno twego oprogramowania tam być.

_13th_Dragon napisał(a):

Jeżeli to nie jest sieć lokalna zaś "klienci" są za maskardą to nie powinno twego oprogramowania tam być.

Nie, to nie jest sieć lokalna. Dlaczego nie powinno tam być mojego oprogramowania? W jakim sensie?

Kofcio napisał(a):

Nie, to nie jest sieć lokalna. Dlaczego nie powinno tam być mojego oprogramowania? W jakim sensie?

Bo to mi wygląda na oprogramowanie szpiegujące.

_13th_Dragon napisał(a):

Kofcio napisał(a):

Nie, to nie jest sieć lokalna. Dlaczego nie powinno tam być mojego oprogramowania? W jakim sensie?

Bo to mi wygląda na oprogramowanie szpiegujące.

Nie, to nie tak. Oprogramowanie będzie instalowane za pełną zgodą właściciela urządzenia i będzie wyświetlało dane z jego bazy danych użytkownikom, którym nada takie uprawnienia. Chodzi o możliwość wyświetlania danych, które są na różnych serwerach w różnych sieciach innym użytkownikom.

Przykładowo:
Biuro rachunkowe ma program księgowy z bazą danych dla każdego swojego klienta i chciałoby aby każdy klient i część jego pracowników miał dostęp do wybranych danych z tego programu księgowego. W tym celu zakłada konto na mojej stronie -> ja udostępniam program, który musi być zainstalowany i skonfigurowany na ich serwerze i dzięki temu klient ma dostęp do swoich danych za pośrednictwem mojej strony a ja nie muszę udostępniać mu swojej aplikacji (jest ona na moim serwerze etc. i komunikuje się z jego stroną). Tak więc mamy jeden serwer główny z moją stroną www oraz N serwerów klientów, którzy mają wgląd do swoich danych.
Dane serwerów, do których aplikacja ma dostęp (adres IP, port, etc.) zapisywane będą na głównym serwerze dzięki czemu aplikacja będzie wiedzieć skąd brać dane.

No i zastanawiam się czy nie będzie tu jakiś problemów w zakresie m.in. zmiennego numeru IP czy IPv6 (małe firmy często nawet stałego IP nie mają). Do tej pory upubliczniałem strony jedynie na serwerach, gdzie była domena etc. i takie problemy nie występowały.

Oprogramowanie na komputerze klienta łączy się do twego serwera i przekazuje to co trzeba, jedynie musisz zadbać aby twój serwer miał stały adres (niekoniecznie stały IP).
Ba twój serwer może być nawet rozproszony, sprawdź w czasie aktywności IP strony www.google.pl
ping www.google.pl potrafi się zmienić pomiędzy pingami.

_13th_Dragon napisał(a):

Oprogramowanie na komputerze klienta łączy się do twego serwera i przekazuje to co trzeba, jedynie musisz zadbać aby twój serwer miał stały adres (niekoniecznie stały IP).
Ba twój serwer może być nawet rozproszony, sprawdź w czasie aktywności IP strony www.google.pl
ping www.google.pl potrafi się zmienić pomiędzy pingami.

Czyli mówisz, że jak moja aplikacja (strona www) będzie chciała pobrać dane klienta to ma wysłać request do mojego WebApi -> następnie moje WebApi ma wysłać request na serwer klienta -> pobrać stamtąd dane i wyświetlić je klientowi?
Nie lepiej aby strona www (SPA) od razu łączyła się z serwerem klienta i pobierała stamtąd dane?

Jeżeli jak twierdzisz, to nie jest oprogramowanie szpiegowskie to kontrola nad wysyłką powinna leżeć po stronie klienta.
Więc to mikro serwis powinien sam zgłaszać do serwera dane które klient udostępnił po każdej zmianie udostępnionych danych.
Z tym że czy ty nie próbujesz wymyślić bardziej okrągłe koło niż dotychczas istniejące?
Bo to o czym piszesz to chmura.

A ta cała architektura to jaki problem ma rozwiązać?
Bo jak na razie, to ja w ogóle nie widzę tam miejsca ani na żadne przesyłanie adresów IP ani na "serwer główny".

somekind napisał(a):

A ta cała architektura to jaki problem ma rozwiązać?
Bo jak na razie, to ja w ogóle nie widzę tam miejsca ani na żadne przesyłanie adresów IP ani na "serwer główny".

Mam stronę www (SPA), która łączy się z moim serwerem głównym na którym jest baza danych z użytkownikami oraz jakieś dodatkowe rzeczy, które są tworzone bezpośrednio na tej stronie. To są "moje" dane - tj. takie, które zostały utworzone bezpośrednio na mojej stronie. Użytkownik się loguje -> dostaje JWT podpisany moim kluczem -> ma dostęp do wybranych rzeczy.

Ale na stronie chcę również umożliwić wyświetlanie użytkownikom informacje, które są zapisane w bazie danych innego użytkownika, który je udostępnił. Głównie chodzi o dane księgowe z programu księgowego tego użytkownika. Nie chcę ich przesyłać i zapisywać na swoim serwerze - chcę je tylko wyświetlać na stronie.

Czyli mamy np. biuro rachunkowe, które ma na swoim serwerze program księgowy z bazą danych i chce (to biuro rachunkowe chce) udostępnić te dane swoim klientom. Baza danych jest zainstalowana lokalnie a nie w chmurze etc. Dodatkowo biuro może mieć zmienny adres IP.
Klienci tego biura mają mieć dostęp do danych z każdego miejsca.

W tym celu biuro rachunkowe instaluje moją aplikację (WebApi) na swoim serwerze (na którym jest baza danych programu księgowego). WebApi dostaje ode mnie klucz (jakiś losowy ciąg znaków), który jednocześnie jest kluczem dla drugiego JWT w celu łączenia się z tym WebApi. Na serwerze głównym przechowuję ten klucz i przy logowaniu się użytkownik dostaje drugi JWT z dostępem do tej firmy - dzięki temu może wysyłać żądania na serwer biura rachunkowego.

Czy teraz ma to sens?

@_13th_Dragon przepraszam, ale nie jestem pewny czy dobrze rozumiem.

_13th_Dragon napisał(a):

Jeżeli jak twierdzisz, to nie jest oprogramowanie szpiegowskie to kontrola nad wysyłką powinna leżeć po stronie klienta.

No i tak właśnie będzie. Aplikacja zainstalowana po stronie klienta (WebApi) będzie zabezpieczone JWT bez którego nie udostępni danych użytkownikowi.
Jeżeli użytkownik nie uzyskał dostępu to nie wygeneruje mu się również JWT do tego serwera.

_13th_Dragon napisał(a):

Więc to mikro serwis powinien sam zgłaszać do serwera dane które klient udostępnił po każdej zmianie udostępnionych danych.

Czym według Ciebie jest mikro serwis? Mowa o aplikacji zainstalowanej na serwerze klienta (biura rachunkowego), moją stronę www?

_13th_Dragon napisał(a):

Z tym że czy ty nie próbujesz wymyślić bardziej okrągłe koło niż dotychczas istniejące?
Bo to o czym piszesz to chmura.

Nie, bo nie chodzi o udostępnienie plików etc. tylko samych danych z programu księgowego np. informacji jakie dokumenty zostały już zaksięgowane, jaki jest wynik finansowy, jakie są nieobecności pracowników etc. Taki pulpit managera. Dlatego, że program księgowy jest poza firmą a często trzeba mieć dostęp do danych to chcę umożliwić wyświetlanie tych danych.

Kofcio napisał(a):

Czy teraz ma to sens?

Opis jest zrozumiały, ale czy to ma sens, to nie wiem.
Ty to robisz dla siebie, jako jakieś zadanie z programowania, czy chcesz to komuś sprzedawać? Bo jeśli to produkt komercyjny, to ja bym się najpierw zastanowił, czy ktoś pójdzie na takie karkołomne rozwiązanie wymuszające stawianie jakichś serwerów z API u siebie, ale z GUI w internecie.

A technicznie, to serwery u klientów muszą jakoś cyklicznie informować serwer centralny o swoim aktualnym zewnętrznym IP, wysyłając jakiegoś heartbeata co określony interwał, i tyle. Nie wiem jak to będzie działać, bo taki serwer u klienta pewnie będzie w wewnętrznej sieci, za jakimś NATem, więc tam dojdzie przekierowywanie portów i inne cudowanie.

somekind napisał(a):

Kofcio napisał(a):

Czy teraz ma to sens?

Opis jest zrozumiały, ale czy to ma sens, to nie wiem.
Ty to robisz dla siebie, jako jakieś zadanie z programowania, czy chcesz to komuś sprzedawać? Bo jeśli to produkt komercyjny, to ja bym się najpierw zastanowił, czy ktoś pójdzie na takie karkołomne rozwiązanie wymuszające stawianie jakichś serwerów z API u siebie, ale z GUI w internecie.

Robię to głównie dla siebie i dla znajomych, w tym biur rachunkowych z którymi współpracuję lub będę współpracował. Jak coś z tego wyjdzie (biorę pod uwagę porażkę) to być może będę myślał nad komercjalizacją, ale to dopiero za kilka lat (robię to w wolnym czasie).

Sam jestem księgowym, który pracuje w biurze rachunkowym i takie rozwiązanie bardzo by się przydało. Nie chcę stawiać całej strony na serwerze biura bo to moja własność intelektualna i w razie takiej potrzeby chcę mieć możliwość jej odłączenia.
Podobne strony już istnieją (chociaż chyba działają na innej zasadzie niż ta zaproponowana przeze mnie), ale ja chcę mieć coś swojego :P. Dobre ćwiczenie z programowania :).

somekind napisał(a):

A technicznie, to serwery u klientów muszą jakoś cyklicznie informować serwer centralny o swoim aktualnym zewnętrznym IP, wysyłając jakiegoś heartbeata co określony interwał, i tyle. Nie wiem jak to będzie działać, bo taki serwer u klienta pewnie będzie w wewnętrznej sieci, za jakimś NATem, więc tam dojdzie przekierowywanie portów i inne cudowanie.

Dokładnie taka jest idea :).

Najbliżej tego co opisujesz spotkałem się w rozwiązaniach korporacyjnych.
Spotkałem się z czymś takim przynajmniej kilka razy.

Aplikacja, która jest uruchamiana na komputerach/serwerach klientów, łączy się z Twoim serwerem tworząc tunel oraz utrzymując połączenie.
Następnie pobierasz dane, które są potrzebne w aplikacji i prezentujesz je - użytkownikowi końcowemu.

Zalety?

1. Klient nie musi mieć publicznego IP.
2. Bezpieczne o ile zostanie mądrze wykonane (odpowiednia separacja).
3. Możliwość rozszerzania o nowe serwery, gdyby czegoś zabrakło (np. transferu).
4. Wyższa wydajność oraz czas reakcji (o ile zostanie dobrze wykonane).

Wady?
Wykonanie tego wymaga sporej wiedzy.

Dodatkowo możesz się pokusić o szyfrowanie end-end. Wtedy odpada Ci wiele punktów z RODO odnośnie przetwarzania danych.
W takim przypadku odpowiedzialność za przetwarzanie danych zrzucasz całkowicie na klientów (bo tylko je przekazujesz w formie zaszyfrowanej).
Oczywiście musi to być dobrze zrobione.

Jeśli chodzi o dystrybucję oprogramowania, urzędy certyfikacji (CA) oraz inne związane z tym zagadnienia to już zależy od Twojej sfery biznesowej.

malencki napisał(a):

Aplikacja, która jest uruchamiana na komputerach/serwerach klientów, łączy się z Twoim serwerem tworząc tunel oraz utrzymując połączenie.
Następnie pobierasz dane, które są potrzebne w aplikacji i prezentujesz je - użytkownikowi końcowemu.

Rozumiem, że piszesz o VPN-ie?
Takie rozwiązanie trochę by ułatwiło, bo miałbym bezpośredni dostęp do bazy danych.
Z drugiej strony powoduje, że dane idą od biura rachunkowego do mnie a później do użytkownika - czyli trochę na około.
Dodatkowo zastanawiam się czy nie będzie problemu, gdy będę hostował stronę przez jakiś zewnętrzny serwer...
No i pytanie czy każdy user będzie miał możliwość utworzenia tego tunelu?

@Kofcio To nie musi być VPN. Może to być zwykłe połączenie z aplikacją (takie spotykałem).
Taki tunel jest tworzony i utrzymywany przez Twoją aplikację u klienta (serwer gdzie znajduje się aplikacja księgowa).

Co do chodzenia danych "na około".
Można próbować coś takiego zrobić, żeby Twój serwer udostępniał tylko dane do połączenia.
Niestety komplikuje to rozwiązanie dodatkowo serwery klientów muszą mieć publiczny IP inaczej robi się ciekawie (i nie zawsze będzie działało).

Przy połączeniu tym "tunelowym", masz załatwioną autoryzację i bezpieczne połączenie za jednym zamachem.
Potem takie połączenie tylko pollujesz, aby nie wygasło.

Jeżeli robisz to po godzinach i nie chcesz potem poświęcać dużo czasu na utrzymywanie tego (np. na aktualizację aplikacji, bo pojawiła się jakaś luka bezpieczeństwa w .NET) to VPN jest pewnie najlepszym rozwiązaniem. Wtedy możesz bezpośrednio łączyć się do poszczególnych baz danych i zabezpieczasz się przez nipowałonym dostępem z zewnątrz.