Trebuie să utilizez numele de utilizator sau ID-ul utilizatorului pentru a trimite utilizatori autentificați în ASP.NET

Deci, în site-ul meu simplu de învățare, folosesc sistemul de autentificare ASP.NET.

Acum adaug un tabel de utilizator pentru a salva chestii precum zipul, DOB etc. Intrebarea mea este:

  1. În noul tabel, dacă cheia este numele de utilizator (șirul) sau ID-ul de utilizator care este acel număr de identificare GUID pe care îl utilizează în tabelele asp_ .
  2. În cazul în care cea mai bună practică este de a folosi ghidul urât, știe cineva cum să o obțină? se pare că nu este accesibil la fel de ușor ca numele ( System.Web.HttpContext.Current.User.Identity.Name )
  3. Dacă vă sugerăm să nu folosesc nici unul (nu câmpul guid, nici userName furnizat de autentificarea ASP.NET) atunci cum îl fac cu autentificarea ASP.NET? O opțiune care îmi place este să folosesc adresa de e-mail a utilizatorului ca autentificare, dar cum să fac sistemul de autentificare ASP.NET să utilizeze o adresă de e-mail în loc de un nume de utilizator? (sau nu există nimic de făcut acolo, doar eu mă decid "știu" numele de utilizator este de fapt o adresă de e-mail?

Vă rugăm să rețineți:

  • Nu vă întreb despre cum să obțineți un GUID în .NET, mă refer doar la coloana userID din tabelele asp_ ca guid.
  • Numele de utilizator este unic în autentificarea ASP.NET.
0
fr hi bn

12 răspunsuri

Sunt de acsaud cu Mike Stone. Aș sugera, de asemenea, să folosiți doar un GUID în cazul în care veți urmări o cantitate ensaumă de date. În caz contrar, este suficientă o singură coloană cu număr întreg simplu (incremental) (Id).

Dacă aveți nevoie de GUID, .NET este destul de minunat încât să puteți obține una printr-un simplu ...

Dim guidProduct As Guid = Guid.NewGuid()

sau

Guid guidProduct = Guid.NewGuid();
0
adăugat

Ar trebui să utilizați un ID unic, fie GUID pe care îl menționați, fie o altă cheie generată automat. Cu toate acestea, acest număr nu ar trebui să fie vizibil pentru utilizator.

Un avantaj imens al acestui lucru este că tot codul dvs. poate funcționa pe ID-ul de utilizator, dar numele utilizatorului nu este într-adevăr legat de acesta. Apoi, utilizatorul își poate schimba numele (pe care l-am găsit util pe site-uri). Acest lucru este util mai ales dacă folosiți adresa de e-mail ca autentificare a utilizatorului ... ceea ce este foarte convenabil pentru utilizatori (atunci nu trebuie să-și amintească 20 de ID-uri în cazul în care identificatorul lor comun este unul popular).

0
adăugat

Aș sugera să folosiți numele de utilizator ca cheie primară în tabel dacă numele de utilizator va fi unic, există câteva motive bune pentru a face acest lucru:

  1. Cheia primară va fi un index grupat și, prin urmare, căutarea detaliilor utilizatorilor prin numele de utilizator va fi foarte rapidă.
  2. Se va opri apariția numelor de nume duplicate
  3. Nu trebuie să vă faceți griji cu privire la utilizarea a două tipuri diferite de informații (nume de utilizator sau ghid)
  4. Aceasta va face codul de scriere mult mai ușor din cauza faptului că nu trebuie să căutați doi biți de informații.
0
adăugat
Problema cheie cu utilizarea numelui de utilizator este dacă utilizatorul dorește să își schimbe numele de utilizator din anumite motive. Dacă utilizați numele de utilizator, va trebui să efectuați modificări în mai multe tabele în loc de unul singur. Notă: a făcut acest comentariu apoi citiți mai jos și a văzut altcineva a menționat acest lucru.
adăugat autor percent20, sursa
O altă problemă potențială apare atunci când numele de utilizator pot fi refolosite în timp. De exemplu, să presupunem că utilizați numele de utilizator în modelul de autorizare personalizat. User ASmith este atribuit ca administrator. Apoi, el părăsește compania, iar înregistrarea utilizatorului este ștearsă. Un nou utilizator se alătură companiei și îi este atribuit numele de utilizator ASmith. Ați dat potențial doar accesul administratorului de utilizator fără ao realiza.
adăugat autor Phil Haselden, sursa

Dacă intenționați să utilizați LinqToSql pentru dezvoltare, aș recomanda utilizarea unui Int ca o cheie primară. Am avut multe probleme când am avut relații construite din câmpuri non-Int, chiar și atunci când câmpul nvarchar (x) avea constrângeri să-l transforme într-un câmp unic.

Nu sunt sigur dacă acest lucru este un bug cunoscut în LinqToSql sau ce, dar am avut probleme cu acesta pe un proiect curent și a trebuit să fac schimb de PK și FK pe mai multe mese.

0
adăugat

Sunt de acord și cu Mike Stone. Compania mea a implementat recent un nou tabel de utilizatori pentru clienții externi (spre deosebire de utilizatorii interni care se autentifică prin LDAP). Pentru utilizatorii externi, am ales să stocăm GUID ca cheie primară și să stocăm numele de utilizator ca varchar cu constrângeri unice pe câmpul cu numele de utilizator.

De asemenea, dacă intenționați să stocați câmpul de parolă, recomandăm stocarea parolei ca bază binară sărată în baza de date. În acest fel, dacă cineva ar fi hacking baza de date, nu ar avea acces la parolele clientului tău.

0
adăugat

Ar trebui să utilizați ID-ul de utilizator. Este proprietatea ProviderUserKey a utilizatorului MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
0
adăugat
Aveți o paranteză suplimentară închisă după .Identity.Name
adăugat autor Marcel Popescu, sursa

Mi-ar folosi un userid. Dacă doriți să utilizați un nume de utilizator, veți face caracterul "modificați numele de utilizator" foarte scump.

0
adăugat

Aș spune să utilizați ID-ul utilizatorului, astfel încât numele de utilizator pot fi modificate fără a afecta cheia primară. De asemenea, aș seta coloana cu nume de utilizator pentru a fi unică pentru a opri numele de utilizator duplicat.

Dacă veți căuta mai degrabă numele de utilizator decât numele de utilizator, faceți apoi numele de utilizator un index în grup și setați cheia primară să nu fie clustered. Acest lucru vă va oferi cel mai rapid acces la căutarea numelor de utilizator, dacă totuși veți căuta în principal UserIds, apoi lăsați acest lucru ca indice cluster.

Editare: Se va potrivi mai bine cu tabelele de membru ASP.Net curente, deoarece acestea utilizează și ID-ul de utilizator ca cheie primară.

0
adăugat

Aș folosi un număr de incrementare automată, de obicei un int.

Doriți să păstrați dimensiunea cheii cât mai mică posibil. Acest lucru păstrează indexul dvs. mic și beneficiază de orice chei străine, de asemenea. În plus, nu sunteți legat strâns de designul de date la datele de utilizator externe (acest lucru este valabil și pentru GUID-ul aspnet).

În general, GUID-urile nu fac chei primare bune, deoarece acestea sunt mari, iar inserțiile se pot întâmpla la orice pagină de date potențial din tabel, mai degrabă decât la ultima pagină de date. Principala excepție este dacă executați baze de date reptilă mutilple. GUID-urile sunt foarte utile pentru cheile din acest scenariu, dar cred că aveți doar o singură bază de date, deci nu este o problemă.

0
adăugat

Sunt de acord cu Palmsey, Deși pare să existe o mică eroare în codul său:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

ar trebui să fie

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
0
adăugat

Aș folosi ghidul în codul meu și așa cum am menționat deja o adresă de e-mail ca nume de utilizator. Este, la urma urmei, deja unic și memorabil pentru utilizator. Poate chiar șterge guidul (v. Discutabil).

Cineva a menționat folosind un indice cluster pe GUID dacă acesta a fost folosit în codul dvs. Aș evita acest lucru, mai ales dacă INSERT-urile sunt mari; indexul va fi reconstruit de fiecare dată când inserați o înregistrare. Clusterele indexurilor funcționează bine pe ID-urile incrementării automate, deși noile înregistrări sunt atașate numai.

0
adăugat

Acest lucru este vechi, dar vreau doar oamenii care găsesc acest lucru să noteze câteva lucruri:

  1. baza de date aspnet este optimizată atunci când vine vorba de accesarea înregistrărilor utilizatorilor. Indicele grupat caută (optim) în serverul sql este utilizat atunci când se caută o înregistrare utilizând numele și numele aplicației loweredus. Acest lucru are multe sens, deoarece avem doar numele de utilizator furnizat pentru a continua atunci când utilizatorul trimite mai întâi acreditările.

  2. Ghidul utilizatorului ghid va da o dimensiune mai mare a indexului decât un int, dar acest lucru nu este semnificativ, deoarece adesea recuperează doar 1 înregistrare (utilizator) la un moment dat și în termeni de fragmentare, numărul de citiri depășește de obicei greu numărul de scrieri și modificări la un tabel de utilizatori - oamenii pur și simplu nu actualizează acele informații tot timpul.

  3. scriptul regsql care creează tabelele de membri aspnet poate fi editat astfel încât, în loc să utilizeze NEWID ca implicit pentru userid, poate folosi NEWSEQUENTIALID() care oferă o performanță mai bună (am profilat acest lucru). >

  4. Profil. Cineva care creează un "site nou de învățare" nu ar trebui să încerce să reinventeze roata. Unul dintre site-urile pe care le-am lucrat pentru a utiliza o versiune exceptată de la casetă a tabelelor de membri aspnet (excluzând sistemul de profil oribil) și tabela utilizatorilor conțineau aproape 2 milioane de înregistrări ale utilizatorilor. Chiar și cu un număr atât de mare de înregistrări, selecțiile au fost încă rapide deoarece, așa cum am spus pentru început, indicele bazei de date se concentrează pe numele redus de aplicație + pe aplicația pe indexul grupat peformă caută aceste înregistrări și, în general, dacă SQL face un index în grup pentru a găsi o înregistrare, nu aveți probleme, chiar și cu un număr mare de înregistrări, cu condiția să nu adăugați coloane în tabele și să începeți să trageți prea multe date.

  5. Îmi este îngrijorat de un guid în acest sistem, pentru mine, bazat pe performanța reală și experiența sistemului, este o optimizare prematură. Dacă aveți un int pentru useridul dvs., dar sistemul efectuează interogări suboptimale din cauza designului personalizat al indexului dvs., sistemul nu va scala bine. Băieții Microsoft au făcut o treabă în general bună cu aspb membership db și există multe lucruri mai productive pe care să vă concentrați asupra schimbării userId la int.

0
adăugat