Zarządzanie kontami klientów w aplikacji pod Symfony3

0

Hej,

od jakiegoś czasu piszę aplikację w Symfony (długa i złożona historia - jak ktoś ciekawy, to opiszę)...
Jako że widzę (skromne, ale jednak) zapotrzebowanie (+/- kilkanaście klientów w Polsce), to chciałbym żeby aplikacja była na tyle elastyczny, żeby można było udostępniać/sprzedawać konta z indywidualnymi danymi aplikacji w bazie danych (mam nadzieję, że ostatnie zdanie nie brzmi zbyt kolokwialnie).

W związku z powyższym:

  1. Czy wystarczy dodać identyfikator konta do tabel?
    1.1. Czy do wszystkich? Wydaje mi się że bez tych przejściowych many-to-many
    1.2. Jak wtedy z bezpieczeństwem? Jak "odgrodzić" konta od siebie?
    1.3. Mam obawę, że napisanie systemu zarządzającego też niesie dużo problemów, dlatego spytam się również:
  2. Czy jest jakiś moduł który polecacie taki "accounting? Czy jest moduł ktory oferuje zarazem możliwość wielu kont jak i zarządzanie nimi?
    2.1. Jestem prawie pewny że FOSUserBundle nie oferuje takiej możliwości. Może się mylę?
    2.2. Jeszcze 2 miesiące temu SonataAdminBundle nie działała z Symfony3, a dodatkowo wydaje mi się, że nie oferuje takiej możliwości. Może się mylę?

Pozdrawiam i z góry dziękuję za radę/rady

0

FOS oferuje możliwość obsługi kont użytkowników. Z Twojego opisu wynika, że potrzebujesz właśnie czegoś takiego. Treść tworzona przez danego użytkownika może być przecież przypisana do danego użytkownika (właśnie przez dodanie identyfikatora tego użytkownika do tabeli). Co do sonaty to jakiś czas temu instalowałem ją w projekcie symfony 3 i niemalże wszystko było ok. Jedyny problem (projekt był mały więc pewnie tych problemów może być więcej ) to była integracja z fosem. O ile użytkownikami mogłem zarządzać to nie udało mi się podpiąć menu użytkownika takiego jak jest na 4programmers (avatar itp). Na szczęście tego nie potrzebowałem za bardzo.

0

dziękuję, niestety trochę nieprecyzyjnie się wyraziłem (mea culpa - aż mi trochę głupio). Ma być w aplikacji pewna różnica pomiędzy kontem klienta, a kontem użytkownika aplikacji. Konto klienta może zawierać wiele loginów (abstrakcyjny przykład: 6 użytkowników firmy ABC, z czego np. dwaj zarządcy, jeden doradca, trzech dostawców treści + 11 użytkowników firmy ZYX + 3 użytkowników firmy DEF). Mogę dodać tabelę wiele do wielu typu user_account,jednak pozostają niejasne dla mnie wymienione kwestie (za wyjątkiem pytania 2.2 - dzięki - sprawdzę to na dniach).

0

to co chcesz osiągnąć to SaaS - Software as a Service.
Osobiście nie szedłbym w stronę, o której piszesz. Wszystkie wpisy musiałbym oznaczać id = firmy. Poszedłbym raczej w stronę 1 firma = 1 baza.
Robisz np. jakiś panelik w którym zakładasz firmę -> rezultatem jest puszczenie skryptu generującego bazę z adminem który może tworzyć konta w ramach firmy + tworzysz katalog z apką defaultową.

Wydaje mi się, że posiadanie jednej bazy dla wielu klientów ma dwie głowne wady:

  1. klient A przez przypadek może zobaczyć dane klienta B. Przy wielu bazach jest mniejsza szansa, bo błąd musiałby być w logice zaczytującej dane do bazy po subdoemenie. Jeżeli masz jedną bazę, to w zapytaniach musisz pilnować warunków where tenant_id = ...
  2. performance. Załóżmy, że średnio klient ma 1 000 000 rekordów w jakiejś tabelce, a Ty masz 100 klientów... smile

do tego dochodzi temat kupowania dostępu? może opisz dokładniej co chcesz zrobić. To fajny temat jest.

0

przepraszam zapędziłem się powyżej. Jedna baza per firma ALE jedna aplikacja! Przepraszam

0

Super... dzięki Wybitny Wąż... właśnie liczę na pragmatyczne podejście. Jeszcze poszukam w internecie: jak często stosuje się Twoje rozwiązanie i jakie są wady (i ukryte niebezpieczeństwa). Sprawdzę też w internecie, czy często stosują SaaS pod Symfony3 (dyskusje/bundle/źródła github).... być może społeczność Symfony opanowało zagadnienie wystarczająco dobrze...

Jak chodzi o kupowanie dostępu to zamierzam rozwiązać najmniejszą linią oporu (podobnie jak Twoje rozwiązanie):

Jakiś czas temu, przez kilka niezwykle wyczerpujących miesięcy, kodziłem przy aplikacji typu legacy (spadkowa) obsługującą kilkadziesiąt klientów (firm) i kilkaset użytkowników.
Postaram się ją streścić:

  • pierwotnie napisana na Yii (chyba 60% procent kodu to bajzel dopisywany przez kilku koderów przez kilka lat - rdzenny kod też tak łatany że segregacja m-v-c prawie nie istniała)
  • kilkadziesiąt tabel w bazie danych (może nawet więcej - za pierwszym razem dostałem oczopląsów - także modyfikowana na "łapu capu")
  • każda firma miała swoje id (czyli to rozwiązanie które opisałem na początku)
    Jak tam realizowało się płatności? Naturalnie był moduł płatności, nie tylko kont, ale też usługi i kupony... tylko było małe "ale"... nie był on w zasadzie używany.
    Niemal każda firma wolała pisać e-maile, bądź dzwinić do "właściciela" tej aplikacji, niż się bawić w panelu administracyjnym (szczęśliwie, bo byłoby to mocno ryzykowne).

W przypadku mojej aplikacji, skoro jest "jeszcze bardziej dedykowana" do pewnej branży, to sprawę płatności zostawię na koniec bądź - zupełnie pominę.

pozdrawiam

1 użytkowników online, w tym zalogowanych: 0, gości: 1