Rilevazione è un utente è un amministratore (o qualsiasi tipo) per pagina, provider di appartenenza asp.net mvc di default

Question

Sto costruendo un'applicazione web, e vorrei fare alcune funzioni sul front-end visibile quando un utente è connesso come amministratore.

Sto usando il provider di appartenenze di default, ma ho un tavolo allungabile chiamati UserFields che uso per memorizzare le impostazioni utente.

Ho appena aggiunto un campo UserType a questo tavolo, e ora sto considerando come sarà meglio di scegliere questo sulle pagine.

Non voglio veramente avere per aggiungere codice aggiuntivo per ogni metodo di controllo per ottenere queste informazioni dal db, e farla passare attraverso.

C'è un modo migliore per fare questo, sia utilizzando la funzione integrata nelle impostazioni ruoli in appartenenza asp.net, o c'è un modo intelligente posso esporre queste informazioni dal mio db, nelle opere User.Identity.Name stesso modo o (User.Identity.Name) .ProviderUserKey;

Answer 1

Fino a quando si utilizza il metodo di autenticazione standard che posti l'oggetto utente in un contesto non dovrebbe essere troppo difficile. Secondo lei, utilizzare Html.RenderPartial e il controller appropriato per realizzare ciò che si vuole in questo modo ...

/ Home / Indice Vista:

<div id="menu">
<ul>
<li>Page 1</li>
<li>Page 2</li>
<% Html.RenderPartial("/Home/AdminView"); %>
</ul>
</div>

/ Home / Amministratore Vista:

<li>Admin 1</li>
<li>Admin 2</li>

/ Shared / vuoto:

<!--Empty view for non-viewable admin stuff-->

/ casa Controller:

public ActionResult AdminView()
{
  //Check if user is admin
  //This should be your own logic... I usually have a few static methods that the 
  //Users or User object has to assist with checking
  if (Models.User.IsAdmin(HttpContext.User.Identity.Name))
  {
    return View();
  }
  else
  {
    return View("Empty");
  }
}

Che dovrebbe funzionare ... E 'come lo faccio. Se è sbagliato, si spera che qualcuno più intelligente i messaggi una risposta migliore in modo che possiamo imparare sia

Modifica

Proprio pensato a qualcosa di diverso ... Se l'implementa IPrincipal oggetto utente, si potrebbe estrarre dal contesto, il cast al tipo di utente e hanno il diritto informazioni nella classe utente ...

Un po 'come questo

class User : IPrincipal
{
  //Implement IPrincipal stuff
  public string Role { get; set; }
}

Poi la logica vista amministratore potrebbe essere la seguente:

public ActionResult AdminView()
{
  //Check if user is admin
  //This should be your own logic... I usually have a few static methods that the 
  //Users or User object has to assist with checking
  if ( ((Model.User)HttpContext.User).Role =="Admin" )
  {
    return View();
  }
  else
  {
    return View("Empty");
  }
}

Answer 2

Utilizzare i ruoli asp.net -. Quindi è possibile utilizzare gli attributi di autorizzazione sui controller per garantire che l'utente disponga dei ruoli pertinenti di

Vedere questa domanda .

Questo risolve il problema di un solo permettendo alcune azioni / controller sia accessibile a determinati utenti.

E 'non risolve il problema di rendere solo 'visibile' alcune caratteristiche. Per fare questo è necessario creare sia diversi punti di vista (o parziale) ed il controller (s) sceglie quale al fine di rendere in base ai ruoli -. O si scrive logica specifica ruolo direttamente nella tua vista

Naturalmente se si memorizzano le bandiere per gli utenti in una tabella separata che si può fare tutto questo, sulla base di propri dati. Scrivi la tua attributo di autorizzazione (vale a dire un filtro di autorizzazione), e utilizzare i propri dati per guidare vedute - semplicemente passare alla vista come parte dei dati della vista -. Proprio come qualsiasi altra parte del modello

Tu dici che non vuoi scrivere il codice per passare i dati attraverso il controller per la vista - ma questo è ciò che tipo di controller sono per - è la ragione per cui esistono. Si potrebbe scrivere un metodo statico -. O di un servizio di un certo tipo che l'accesso al DB direttamente dalla vista, bypassando il controller, ma poi si potrebbe anche solo tornare a webforms