Gestione di applicazioni per un solo utente

La tua soluzione (hardcoding) è perfetta per le tue esigenze. Non è necessario implementare un'architettura più complessa.

I normali trucchi sull'autenticazione della password sono ancora validi: non li memorizzano come testo normale ma li cancellano con una funzione hash appropriata. Preferibilmente bcrypt, oppure PBKDF2. La password dovrebbe essere sufficientemente strong. Utilizza la crittografia HTTPS per il tuo sito. Tieni presente che chiunque abbia accesso alla tua configurazione può modificare la password, quindi proteggere l'accesso al tuo server è ancora più importante della protezione dell'accesso all'account amministratore del blog.

Per rispondere alla tua domanda, potresti voler considerare di non "codificarli", specialmente se stai utilizzando un linguaggio compilato. Se lo fai, girare le password è molto più difficile. Dovrai considerare anche cose come:

• Dove memorizzi le password, se in un file assicurati che non sia sfogliabile
• Assicurati che i robot non trovino le tue pagine di accesso (o di post-login)
• Assicurati di aggiungere ancora controlli di autenticazione sulle tue pagine di accesso post e tutte le hidden , quindi devi accedere per vederli
• Hash la password e controlla gli hash, non criptarli e decrittografarli
• Tutto questo dietro SSL

Per offrire un altro approccio, come soluzione più robusta e abbastanza semplice da implementare, suggerirei di utilizzare OAuth e utilizzare un account di accesso Google o social, invece di provare a preparare a casa uno schema di autenticazione. OAuth è abbastanza semplice ora. Se utilizzi Google OAuth "la tua lingua di implementazione" dovresti trovare del codice che è principalmente di trascinamento della selezione.

Ancora un altro approccio, se non lo stai facendo per l'esercizio della codifica di un blog e vuoi semplicemente un blog, ti conviene farlo con un account gratuito come WordPress ... o molti altri.

Di norma solo i professionisti dell'autenticazione devono intraprendere la scrittura di schemi di autenticazione in quanto si tratta di un'area complicata soggetta a errori ... e di attacchi per trovare e sfruttare tali errori.

Se intraprendi questo come un modo per apprendere l'autenticazione e tutta la sua meraviglia, farai un viaggio molto soddisfacente.

Questa è una soluzione perfetta per le tue esigenze immediate e rimane quindi anche se, più tardi, fai torni indietro e aggiungi la capacità per più utenti. NON creare account di database per tutti gli utenti dei client. Così facendo, la gestione delle autorizzazioni molto è più complicata e noiosa, soprattutto per gli utenti finali.

Contrasto tra questi due modelli:

Modello # 1 : account utente individuali nel database.

PLUS: il database si occupa dell'autenticazione; non sono richieste tabelle [utente] aggiuntive.

MINUS: Il database si occupa dell'autenticazione .
Se l'utente dimentica la propria password, non può accedere al database per reimpostare la propria password. Risultati in utenti scontenti, chiamate al service desk, ecc.

MINUS: le autorizzazioni del database devono essere configurate / mantenute per ogni singolo utente. OK, i ruoli lo rendono molto più semplice, ma è ancora un sovraccarico.

Modello n. 2 : account "Applicazione"

PLUS: le connessioni al database vengono effettuate tramite un singolo account con autorizzazioni impostate una volta e lasciate sul posto. Nessun utente mai detiene le credenziali per questo account.

PLUS: le funzionalità di reimpostazione della password possono essere offerte, poiché l'utente può ancora "entrare", anche se ha dimenticato la propria password [applicazione].

MINUS: l'applicazione deve gestire l'autenticazione.
Devi aggiungere tabelle aggiuntive per gestire i "tuoi" utenti, piuttosto che il database che lo fa "per te".