Login-Funktion: nur ein Benutzer mit bestimmten Zugangsdaten

[Mr_G]

Ich habe da eine kleine Verständnisfrage:
Besitzt dein Programm Client und Server oder ist es ursprünglich nur eine Anwendug die von allen ausgeführt werden soll?
Wo (Firmennetzwerk/Internet) soll das denn stattfinden?

[romber]

Natürlich gibt es eine Serverteil und entsprechend ein Client.

[SirThornberry]

die variante einfach einen Wert in die Datenbank zu schreiben das schon jemand eingeloggt ist find ich gar nicht so schlecht. Nur solltest du nicht dem zweiten Nutzer der sich einloggen will dies komplett verbieten sondern einen Hinweis ausgeben das bereits jemand eingeloggt ist und nachfragen ob das ignoriert werden soll. Du könntest ja auch alternativ noch in die Datenbank schreiben wann sich der erste nutzer angemeldet hat und dies im Hinweis mit anzeigen. Wenn dann im Hinweis so was steht wie "Es ist bereits ein Nutzer mit diesen Logindaten angemeldet (login: Vor einer Woche)" dann ist dem zweitanmelder eigentlich sofort klar das jemand das logout vergessen hat und somit kann er sich noch dafür entscheiden die meldung zu ignorieren.

[Mr_G]

Da es einen Client und einen Server gibt ist es denke ich wirklich eleganter die Benutzerverwaltung in das Programm zu intigrieren als extra ein ActiveDirectory aufzusetzen.

Zitat von SirThornberry:

... Nur solltest du nicht dem zweiten Nutzer der sich einloggen will dies komplett verbieten sondern einen Hinweis ausgeben das bereits jemand eingeloggt ist und nachfragen ob das ignoriert werden soll. ...

Ich finde die Lösung mit einer "Ich lebe noch"-Nachricht des Clients etwas eleganter aber es kann sicher nicht schaden die An- und Abmeldungen zu Protkollieren und dem Benutzer zu sagen was Sache ist (z.B. wenn er sich schon eingeloggt hat).

[Jelly]

Hat überhaupt einer meinen Beitrag über die sysprocesses Tabelle beim MSSQL Server gelesen. Da läuft diese ganze "Ich bin da" Sache doch komplett im Hintergrund ab. Warum das Rad neu erfinden?

[romber]

Zitat von Jelly:

Hat überhaupt einer meinen Beitrag über die sysprocesses Tabelle beim MSSQL Server gelesen. Da läuft diese ganze "Ich bin da" Sache doch komplett im Hintergrund ab. Warum das Rad neu erfinden?

Ja, aber um diese sysprocesses Tebelle einzusetzen, muss ich jede Instanz meines Programms mit MSSQL-Server verbinden oder wie? Das möchte ich nicht unbedingt haben.

[Mr_G]

Zitat von romber:

Ja, aber um diese sysprocesses Tebelle einzusetzen, muss ich jede Instanz meines Programms mit MSSQL-Server verbinden oder wie? Das möchte ich nicht unbedingt haben.

Stimmt... Du müsstest jedes Mal zu der Datenbank Connecten.
Wenn du die Benutzer allerdings in deinem Programm verwalten würdest könnte man sich das ersparen in dem dein Server-Proggi die Benutzerdatenbank verwaltet. Somit müssten die Clients nur wie gewohnt zu deinem Server connecten.
Man könnte natürlich zu deinem Server connecten der dann wiederum zur MSSQL-DB connected aber naja ...

[Jelly]

Zitat von Mr_G:

Wenn du die Benutzer allerdings in deinem Programm verwalten würdest könnte man sich das ersparen in dem dein Server-Proggi die Benutzerdatenbank verwaltet. Somit müssten die Clients nur wie gewohnt zu deinem Server connecten.

Und du denkst die selbstgebastelte Lösung läuft so stabil wie die im SQL Server integrierte

Ich bleib dabei... Wenn ein SQL Server zur Verfügung steht, dann würd ich den nutzen. Damit gehst du nämlich sämtlichen evntuell auftretenden Problemen aus dem Weg... Ich habs grad getestet. Mein Programm verbindet sich mit dem SQL Server, unter dem Windowsaccount. Dadruch taucht eine Zeile in der sysprocess Tabelle auf. Ich knall mein Programm über den Taskmanager ab. Und 1 Sekunde später verschwindet der Eintrag in der Tabelle. Also mal im Ernst. Was ist daran so problematisch. Wer natürlich lieber mit Sockets und Server und Clients rumspielt, bitte schön. Ich bin der Meinung das ist das Rad neu erfinden... Und geschweige denn, obs denn auch nachher wirklich schön rund wird.

[romber]

Zitat von Jelly:

Und du denkst die selbstgebastelte Lösung läuft so stabil wie die im SQL Server integrierte

Ich bleib dabei... Wenn ein SQL Server zur Verfügung steht, dann würd ich den nutzen. Damit gehst du nämlich sämtlichen evntuell auftretenden Problemen aus dem Weg... Ich habs grad getestet. Mein Programm verbindet sich mit dem SQL Server, unter dem Windowsaccount. Dadruch taucht eine Zeile in der sysprocess Tabelle auf. Ich knall mein Programm über den Taskmanager ab. Und 1 Sekunde später verschwindet der Eintrag in der Tabelle. Also mal im Ernst. Was ist daran so problematisch. Wer natürlich lieber mit Sockets und Server und Clients rumspielt, bitte schön. Ich bin der Meinung das ist das Rad neu erfinden... Und geschweige denn, obs denn auch nachher wirklich schön rund wird.

OK, nehmen wir an, jede Instanz meines Programms stellt eine "stille", nur für Login-Zweck benutzte MSSQL-Verbindung her. Tatsächlich wird einen neuen Datensatz in der Tabelle sysprocesses erstellt, doch wie kann ich den Inhalt der Spalten für meinen Zweck benutzen? Den Datensatz wird doch einfach so erstellt, sobald eine Anwendung mit dem MSSQL Server verbindet. Habe versuch, ein Paar neuen Spalten in der Tabelle zu erstellen um dann damit etwas anzufangen, doch das ging nicht.

[Jelly]

Zitat von romber:

doch wie kann ich den Inhalt der Spalten für meinen Zweck benutzen?

Die Spalten, die dich interessieren werden, sind:

• hostname
• program_name
• nt_username
• loginame

Bei program_name möchte ich noch bemerken, dass da nur was erscheint, wenn du in den Projektoptionen deines Delphi Programms die Versionsinfo mit reinkompilierst, und unten in der Liste einen Wert für Produktname setzt.

loginame ist der Login, mit dem du dich in der Datenbank einloggst. Vorausgesetzt, du nutzt die Windowsauthentifizierung beim SQL Server... Da steht dann sowas wie computername\windowslogin

Mit diesen beiden Spalten hast du doch sämtlich Informationen, die du brauchst. Um deinen Windowslogin im Delphi rauszufinden, kannst du mal die Forensuche bemühen, da sollte sich was finden lassen, ansonsten, kuck dir die beigelegte Komponente mal an. Beim Programmstart verbindest du dich mit dem SQL Server, in eine x-beliebige Datenbank. Sollte nach Möglichkeit eben nicht die Master Datenbank sein. In deiner Datenbank erstellst du eine View

SQL-Code:

create view vwLogins as
select hostname, program_name, nt_username, loginame from master.dbo.sysprocesses
where program_name='Dein Programmname'

wobei 'Dein Programmname' dem Produktnamen in den Delphi Projektoptionen entsprechen muss. Diese View muss also nicht in der Master Tabelle erzeugt werden. Auf diese View gibst du lediglich Lesezugriff für all deine Benutzer im Netz.

Zitat von romber:

Den Datensatz wird doch einfach so erstellt, sobald eine Anwendung mit dem MSSQL Server verbindet.

Korrekt... Und um jetzt zu prüfen, ob die Anwendung schon sonstwo läuft, zählst du einfach die Records aus deiner View, die deinem nt_username entsprechen. Ist die Anzahl 1, so bist du der erste. Ist sie grösser eins, so läuft die Anwendung bereits.

Zitat von romber:

Habe versuch, ein Paar neuen Spalten in der Tabelle zu erstellen um dann damit etwas anzufangen, doch das ging nicht.

Böser Fehler... sysprocesses ist eine Systemtabell vom SQL Server, und da fummelt man nicht dran rum. Würd mich wundern, wenn du da überhaupt was ändern darfst.

Also nochmal zusammengefasst... Lege dir eine Datenbank an, erstelle die besagte View, und vergib die Recht an deine Domain User im SQL Server auf diese View. Bei deinem Programmstart verbindest du dich einfach mit der Datenbank. Wenn alles korrekt konfiguriert ist, brauchst du dazu kein Login und Passwort, da der Windowsaccount dafür benutzt wird. Fehlt das schon fehl, weil du diesem Windowsaccount nicht erlaubst, in die DB einzuloggen, kannst du ja schon gleich den Programmstart verweigern. Ansonsten zählst du die Records in der View die deinem nt_usernam entsprechen, also etwa

select count(*) as N from vwLogins where nt_username='DeinWindowsLogin' Ist N=1, so darfst du das Programm starten. Ist N > 1, halt nicht.