Archiviazione degli utenti dell'applicazione in SQL: creare una nuova tabella "Utenti" o utilizzare la gestione utenti del database integrata?

Un altro vantaggio dell'utilizzo dell'account pubblicitario o di quello simile è che nel tuo stesso database puoi eseguire funzioni incorporate per capire chi ha effettuato l'accesso. Ciò può essere utile per cose come il controllo o per sapere chi sta accedendo al tuo database in qualsiasi momento utilizzando gli strumenti forniti dal tuo database.

Tuttavia, come accennato in precedenza, questo non si adatta particolarmente bene. Un sacco di connessioni aperte sul tuo database tramite diversi utenti è costoso in termini di risorse del server.

Utilizzando uno degli scenari, per le app più grandi, avrai una tabella utenti in entrambi i casi. Qualunque sia il metodo di autenticazione che usi, una volta che sai chi è quell'utente, probabilmente avrai bisogno di sapere di più su di loro - quale data se la nascita è, la loro nazionalità, i limiti dell'autorizzazione finanziaria, il permesso di cliccare sul pulsante Salva ... Molto spesso tu userà una tabella utenti e tabelle associate per memorizzare tutto ciò che è necessario sapere per l'app.

Alcuni framework, come ad esempio asp.net, forniscono strumenti che forniranno automaticamente modelli per la manutenzione delle proprie tabelle utente.

La gestione utenti del database ha lo scopo di fornire un meccanismo per consentire agli utenti di accedere al database stesso. Usarlo per memorizzare, ad esempio, gli account dei tuoi clienti, è una perversione: non è mai stato progettato per questo. Riutilizzando questo meccanismo per qualcos'altro, stai riducendo il livello di sicurezza del tuo database, soprattutto se non hai un DBA in grado di configurare gli aspetti di sicurezza in modo impeccabile.

Se utilizzi SQL Server in modalità mista (ad esempio, puoi autenticare utilizzando non solo le credenziali di Active Directory, ma anche fornendo un nome utente e una password), non dovresti farlo in primo luogo.

Se ti stai chiedendo se gli account di Active Directory possono sostituire la tabella User (in particolare il tuo punto "Ciò potrebbe consentire una configurazione semplice di accesso singolo su sistemi basati su Windows"), quindi vedi la domanda recente: Utilizzo di un servizio di directory invece di un database .

Quando sviluppi applicazioni desktop per un ufficio clienti, per account utente possono avere molti vantaggi (sicurezza integrata ecc.)

Ma per le applicazioni Web con potenzialmente 1000000 di utenti, è abbastanza comune utilizzare un account di servizio sul server SQL ed eseguire una tabella utenti personalizzata che renda l'opzione selfservice degli account un'opzione praticabile. Assicurati di utilizzare la crittografia corretta (sale e hash) per le tue password!

In SQL Server, si creano accessi a livello di istanza e utenti a livello di database. Ciò può essere fonte di confusione, ma considera che l'accesso all'istanza è per ottenere effettivamente l'accesso agli oggetti di istanza, mentre gli utenti devono assegnare ruoli e diritti nel database. Se, ad esempio, si ripristina un database da una macchina con un set di accessi a un'altra istanza su un'altra macchina, gli accessi saranno solo quelli configurati sulla destinazione, mentre gli utenti saranno comunque inclusi nel database ripristinato - possono solo effettua il login.

Se utilizzi la sicurezza integrata di Windows, questo è tutto ciò che devi fare. Puoi salvare il nome utente in una colonna come mostrato:

'inserire in [Aziende] (DateAdded, AddedBy)
'valori (convert (varchar (50), getdate ()),
'USER_NAME (DATABASE_PRINCIPAL_ID ()))

Se hai migliaia di abbonati web, devi definire il tuo livello di sicurezza. Se si utilizza ASP.NET, è possibile creare un progetto basato sul Web in cui il programma Visual Studio scriverà tutto ciò per cui si desidera iniziare.