2013-04-19 12 views
5

Questa sembrerà una domanda stupida, ma mi chiedo solo se mi manca un trucco da nessuna parte.Il modo migliore per garantire che gli utenti registrati si limitino a vedere i loro dati

Lo scenario è che ho un'applicazione Web che utilizza Simple Memebership, dove gli utenti possono registrarsi per usarlo (programma di fatturazione per esempio).

Tuttavia, dovrebbero essere in grado di visualizzare/aggiornare/rimuovere solo le informazioni che essi stessi aggiungono al database/app web.

Qual è il modo migliore per garantire che l'utente acceda solo alle proprie informazioni?

E 'per aggiungere un campo Nome utente per ogni tavolo, ad esempio:

public class Invoice 
{ 
    public int InvoiceId { get; set; } 
    public int CustId { get; set; } 
    public string UserName { get; set; } 
} 

public class Item 
{ 
    public int ItemId { get; set; } 
    public int InvoiceId { get; set; } 
    public string UserName { get; set; } 
} 

... e poi in qualsiasi controller che accede ai dati, è sufficiente aggiungere un controllo per il nome utente all'interno di ogni query, ad esempio:

var Inv = db.Invoices.Where(x => x.UserName = User.Identity.Name); 
var Itm = db.Items.Where(y => y.UserName = User.Identity.Name); 

che è quello che sto usando attualmente, ma si chiedeva se questa è migliori pratiche? O se c'è un modo più semplice ora siamo su MVC4?

E 'meglio utilizzare UserName o UserId dalla ProfiloUtente tavolo , o che importa?

aggiornamento per aggiungere chiarezza commenti

Così 10 utenti si sono registrati - e tutto ha creato le proprie fatture. Non voglio che nessun utente veda la fattura di altri utenti.

Grazie per qualsiasi consiglio.

Mark

+0

Io non questo deve essere fatto a livello di codice, ma piuttosto a livello di database. Se un utente pubblica qualcosa, il modo migliore è quello di collegare quel post all'utente. Se un utente accede al sito Web, la query deve recuperare tutto ciò che è correlato a quell'utente, quindi non è necessario gestirlo nel codice. – Terry

+0

Come hai potuto farlo ovunque tranne il codice? Il database non saprebbe chi sarà l'utente (scusate se ho perso il vostro punto). grazie – Mark

+0

A un certo punto dell'applicazione, è necessario recuperare le informazioni che l'utente può vedere. A quel punto, sai già chi è l'utente, perché accedono, quindi dovresti avere almeno un userid. Ora quando recuperi le informazioni, usa quell'ID utente per eseguire la tua query e ottenere le informazioni collegate all'utente giusto. – Terry

risposta

2

se si imposta relazioni db correttamente, si dovrebbe essere in grado di fare riferimento ad esempio fatture di un utente in questo modo:

var invoices = dbContext.Users.first(u=>u.id == idParam).Invoices; 

È possibile verificare se una fattura appartiene ad un utente testando

if(dbContext.Invoices.Any(i=>i.invoiceID))//invoice exists? 
{ 
    //Invoice belongs to user? 
    bool invoiceBelongsToUser = dbContext.Users.first(u=>u.id == idParam) 
    .Invoices.Any(i=>i.invoiceID == invoiceIDParam); 
} 
0

È possibile aggiungere il filtro AuthorizeAttribute al file Global.asax per proteggere ogni metodo di azione di ogni controller.

E il controllore non c'è bisogno di essere autorizzato:

[AllowAnonymous] 
public ActionResult LogOn() 

securing-your-asp-net-mvc-3-application

+0

Ciao - scusa se voglio 'chiaro - cosa succede se ci sono due utenti, o duecento utenti che creano tutte le proprie fatture - la mia domanda è: come è meglio impedire loro di vedere tutte le fatture di qualcun altro. Grazie. – Mark

3

cose che vorrei fare sono:

  1. evitare di passare in qualsiasi forma di id utente/credenziale in post/stringa di query, tenere da qualche parte sicuro, come codificato in un cookie, e sempre utente presente quando si costruisce le vostre domande

  2. Se avete ID restituiti al vostro programma come parte di una modifica, assicuratevi che i valori non siano stati manomessi, se uscite l'id in un campo nascosto, assicuratevi che sia lo stesso quando ritorna in quanto uscito (attacco di riferimento diretto si chiama)

  3. se l'applicazione richiede una modifica, come client/modifica/4, assicurarsi sempre che l'ID 4 appartenga a tale utente prima di visualizzarlo.

qualche buona lettura qui sui primi 10 vulnerabilità: https://www.owasp.org/index.php/Top_10_2010-Main

+0

"crittografato in un cookie" non è ancora un posto sicuro. –

+0

Ciao - Sto usando ASP.Net/MVC4 - e token antiforgery e autorizzo attributi etc - quindi avrei sperato che memorizzasse tutto ciò che è necessario per mantenere i dettagli di "utente connesso", all'interno del suo framework e non esposto al cliente. Sarei sbagliato? – Mark

+0

Tutto il token anti falso fa è prevenire gli attacchi xss, devi ancora proteggerti contro i dra – Slicksim

Problemi correlati