Integrationsdienste sind sicher keine Bastellösung. Sie vereinfachen die Nutzung von APIs, und sind genau so verschlüsselt und sicher wie alles andere. 

Unabhängig davon kann man das auch Not Bordmitteln und über den Browser lösen, so dass nur ein User Account “Mitglieder” nötig wäre.

Wenn man eine zweistufige Passwort-Abfrage baut, ein Passwort für alle Mitglieder und ein zweites für das einzelne Mitglied, dann kann man mit select erreichen, dass genau der eine Datensatz angezeigt wird. 

Ob es sinnvoll ist, dass die Mitglieder selbst in die Datenbank schreiben, muss jeder selbst wissen. Ich würde immer über ein externes Formular gehen und einen Kontrollmechanismus in Ninox einbauen. 

... mit Bordmitteln ...

Guten Morgen Oliver, genau deinen Lösungsvorschlag habe ich auch geglaubt umsetzen zu können. Leider geht das nicht. Kurze Erklärung dazu: Es gab eine Untertabelle “Anmeldung”, die bei Datenbankstart aufgerufen wurde und es wurde ein neuer Datensatz erzeugt, wenn sich ein Account in der Rolle “Mitglied” angemeldet hatte. Quasi eine Art Anmelde-Session, um auch mehrere parallele Mitgliederanmeldungen zu ermöglichen. Dann hat sich das Mitglied mit Mitgliedsnummer und einem vertraulichen PIN autentifiziert. Dieser wurde vorab im Mitgliedsprofil hinterlegt und ausgeblendet. Stimmte Mitgliedsnummer und PIN mit dem Datenbestand überein, erfolgte die Weiterleitung zum jeweiligen Mitgliedsprofil bzw. wurden in Ansichten die Rechnungen und sonstigen Vorgänge mit Bezug auf die Mitgliedsnummer angezeigt. Da alles lief in einem Vollmodus, wo sogar die Ninox-Menüleiste links und die Kopfleisten komplett ausgeblendet war (HTML display:none), um andere Bereiche der Datenbank vor Zugriffen zu schützen

Und dann musste ich einen unlösbaren Knackpunkt feststellen: dieser gesamte Prozesse wird komplett ausgehebelt, wenn ein User den Back-Button im Browser benutzt. Dann landet man nämlich in der Datenbank-Basis (die Ansicht, wo die einzelnen Tabellen als Kacheln im rechten Bereich angezeigt werden) und ab dann hätte das Mitglied ungefiltert Zugriff auf alle Datensätze, weil kein Identifizierung des Users mehr möglich ist.

Ich finde seit fast 2 Wochen dafür auch keine Lösung, bin aber gerne für jeden Ratschlag offen.

man kann die Tabellen (alle) auch alst versteckt markieren.

Hallo Leo, das stimmt grundsätzlich. Allerdings sind die Tabellen dann auch für alle anderen Rollen versteckt und ich beraube mich komplett dem Ninox-Menü. Also müsste man wieder ein eigenes Dashboard extra bauen. Grundsätzlich machbar, wenn auch nicht so elegant. Und jetzt das nächste Aber: die Deeplinks. Egal, was man ausblendet, durch das teilweise Kopieren der URL´s komme ich überall hin in der Datenbank, auch wenn ich gar sollte. Denn aus der URL des einzelnen Personendatensatzes kann ich die URL bis auf Ebene der Tabelle extrahieren. Deeplinks sind eigentlich ne tolle Sache. Ich hätte mir nur gewünscht, sie optional auch deaktivieren zu können, denn mit ihnen können leider andere Ninox-Optionen wieder komplett ausgehebelt werden.

Wie gesagt, ich denke die einzige tragfähige Lösung ist es, die Leseberechtigung auf Tabellenebene für den Datensatz mit einem Abgleich zum Ninox-Account zu fahren. Quasi 

Tabelle “Mitglieder” - > Lesbar wenn: userRole(user()) != “Mitglied” or userEmail(user()) = Mitglieder.“E-Mail-Adresse”

Das führt zum Eingangsproblem des Threads zurück, nämlich jedes Mitglied benötigt einen eigenen Ninox-Account = explodiere Kosten für den Verein und zig Accounts, die alle eigene Teams und Datenbanken erstellen könnten, das aber gar nicht wollen oder brauchen, denn sie wollen nur die eine Datenbank nutzen können.

Deeplinks habe ich noch nicht getestet, und da ich mit der Mac-App arbeite, gibt es keinen Zurück-Button. Ob das wirklich in Ninox im Browser nicht zu vermeiden ist, kann ich deshalb nicht einschätzen.

Du kannst das aber problemlos umgehen, in dem du mit www.webcatalog.app eine Ninox-Webapp erstellst, die keinen Zurück-Button anzeigt. Und diese App verteilst du dann. Geht auf Windows, Mac und Linux, was will man mehr? 

Hallo Oliver, 

vielen Dank für den Tipp zu Webcatalog. Ich war zunächst froher Erwartungen und die Idee dahinter ist gar nicht so verkehrt. Allerdings löst das nicht das eigentliche Problem und bringt aber 2 weitere auf: (1) Die Nutzer müssten sich extra die Software installieren und das geht dann auch nur auf Desktop-Geräten, nicht auf mobile devices. Hier sehe ich nur eine sehr geringe Nutzerakzeptanz. (2) Hindert das ja den Nutzer nicht daran, trotzdem sich über den Browser einzuloggen und die o. g. Lücke zu nutzen, um auf Fremddaten zuzugreifen. Zwar kann man mit der Funktion ninoxApp() ja die Browserzugriff feststellen, aber es gibt ja keine Funktion für einen “automatischen Logout” für eine Art Rausschmiss aus der DB.

Ich bin aber für alle Vorschläge offen. Vielleicht hat ja noch jemand eine Idee. 

Bei mobilen Devices hast du doch die nativen Apps, für iPad, iPhone, Android. Da gibt es keine Buttons wie im Browser. Diese Apps sind sogar kostenlos, wenn ich mich richtig erinnere.