[ASP.NET MVC3] Globale variabelen

[frye]

Ik ben sinds enkele dagen na een inleidende cursus me aan het verdiepen in ASP.NET MVC 3.
Het lukt al aardig en heb al een authenticatie voorzien dmv FormsAuthorization.

Mijn lay-out is verdeeld: (1 layout file in shared)
- user info bar
- content
- footer

In deze user info bar wou ik nu de gebruiker welkom heten door zijn naam daar in te plaatsen.
De username heb ik in de authorization cookie die asp.net heeft gecreëerd.

Echter zit ik met een probleem in de user info bar:
Is er een manier om deze naam van de gebruiker in een globale variabelen te plaatsen?
Nu doe ik het door in de home controller in de index action een ViewBag te creëren..
Echter als ik naar een andere controller ga is deze viewbag logischer wijze leeg.

Heb al wat zoekwerk verricht op het internet maar geraak er niet echt uit.

Heeft iemand een duidelijk en simpel voorbeeld om dit te verwezenlijken?

[creator1988]

Maak een AuthController met een Username action die je 'Hello [username]' partial view teruggeeft.

Dan doe je <% Html.Partial("Username", "Auth") %> (ofzoiets) in je template

[ Voor 4% gewijzigd door creator1988 op 27-06-2012 22:55 ]

[R4gnax]

frye schreef op woensdag 27 juni 2012 @ 21:58:
Heb al wat zoekwerk verricht op het internet maar geraak er niet echt uit.

Heeft iemand een duidelijk en simpel voorbeeld om dit te verwezenlijken?

Het klinkt dan ook alsof je een aantal fundamentele misvattingen hebt over hoe forms authenticatie in het algemeen in elkaar zit en hoe je het op ASP.NET MVC toe zou moeten passen. Dat is alleen wel vreemd, want de standaard scaffold voor een MVC3 site heeft nl. al een compleet functionerend login mechanisme. Dus; trek eens een nieuw MVC project open, kies het standaard internet template en begin eens met lezen.

Je zou in ieder geval onder geen enkel beding direct in de authenticatie cookies moeten gaan kijken. Dat is vreselijk, vreselijk bad design waarin je tien lagen te diep aan het werken bent. ASP.NET MVC is een zinnig framework waar zinnige mensen zinnig over nagedacht hebben. Het is niet die troep waar barebone PHP je mee opzadelt. De Controller class heeft een User property, waarmee je een IPrincipal opvraagt die informatie bevat over de huidig ingelogde gebruiker; inclusief de gebruikersnaam. (Deze informatie is niet afhankelijk van forms authenticatie en werkt in principe met elk type authenticatie dat je samen met ASP.NET kunt gebruiken. Dus bijvoorbeeld ook Windows domain authenticatie.

Deze kun je eenvoudig in de viewbag proppen en in je layout view uitlezen, maar dan moet je dat wel in elke controller doen: ASP.NET MVC is in principe stateless (zoals het ook hoort; met de hand zaken in sessions handhaven is in 9 van de 10 gevallen een zeer slecht idee). Beter is om het structureel wat beter aan te pakken via een child action die in je layout pagina aangeroepen wordt.

 

code: Views\Shared\_Layout.cshtml

[...]

@Html.Action("Status", "Account")

[...]

code: Views\Account\Status.cshtml

@model System.Security.Principal.IPrincipal

<strong>@Model.Identity.Name</strong> | @Html.ActionLink("Logout", "Logout")

C#: Controllers\AccountController.cs

public class AccountController : Controller
{
  [ChildActionOnly]
  public ActionResult Status()
  {
    return View( this.User );
  }
  
  /* ... */
}

Alles netjes strongly typed, netjes separation of concerns toegepast en je hoeft niet in al je controllers logica te herhalen. Alleen testability is nog steeds niet zo super, want Controller.User refereert intern aan de HttpContext class en die is heel moeilijk om juist te mocken voor gebruik in unit tests. Daar is echter via een custom model binder nog een vrij elegante oplossing voor te maken.

Het stijgt je nu misschien wel even boven het hoofd, maar het is slim om deze dingen toch even te bestuderen voor je losbrandt. Je hebt er later in het proces veel profijt van als je nu (dwz zo vroeg mogelijk in het leer-/bouwproces) er al over na hebt gedacht.

[ Voor 25% gewijzigd door R4gnax op 28-06-2012 01:10 ]

[HMS]

En dit is niet voldoende om dat te doen? (In het kader van KISS).

C#:

@Context.User.Identity.Name.

[frye]

R4gnax schreef op donderdag 28 juni 2012 @ 00:50:
[...]


Het klinkt dan ook alsof je een aantal fundamentele misvattingen hebt over hoe forms authenticatie in het algemeen in elkaar zit en hoe je het op ASP.NET MVC toe zou moeten passen. Dat is alleen wel vreemd, want de standaard scaffold voor een MVC3 site heeft nl. al een compleet functionerend login mechanisme. Dus; trek eens een nieuw MVC project open, kies het standaard internet template en begin eens met lezen.

Je zou in ieder geval onder geen enkel beding direct in de authenticatie cookies moeten gaan kijken. Dat is vreselijk, vreselijk bad design waarin je tien lagen te diep aan het werken bent. ASP.NET MVC is een zinnig framework waar zinnige mensen zinnig over nagedacht hebben. Het is niet die troep waar barebone PHP je mee opzadelt. De Controller class heeft een User property, waarmee je een IPrincipal opvraagt die informatie bevat over de huidig ingelogde gebruiker; inclusief de gebruikersnaam. (Deze informatie is niet afhankelijk van forms authenticatie en werkt in principe met elk type authenticatie dat je samen met ASP.NET kunt gebruiken. Dus bijvoorbeeld ook Windows domain authenticatie.

Deze kun je eenvoudig in de viewbag proppen en in je layout view uitlezen, maar dan moet je dat wel in elke controller doen: ASP.NET MVC is in principe stateless (zoals het ook hoort; met de hand zaken in sessions handhaven is in 9 van de 10 gevallen een zeer slecht idee). Beter is om het structureel wat beter aan te pakken via een child action die in je layout pagina aangeroepen wordt.

 

code: Views\Shared\_Layout.cshtml

[...]

@Html.Action("Status", "Account")

[...]

code: Views\Account\Status.cshtml

@model System.Security.Principal.IPrincipal

<strong>@Model.Identity.Name</strong> | @Html.ActionLink("Logout", "Logout")

C#: Controllers\AccountController.cs

public class AccountController : Controller
{
  [ChildActionOnly]
  public ActionResult Status()
  {
    return View( this.User );
  }
  
  /* ... */
}

Alles netjes strongly typed, netjes separation of concerns toegepast en je hoeft niet in al je controllers logica te herhalen. Alleen testability is nog steeds niet zo super, want Controller.User refereert intern aan de HttpContext class en die is heel moeilijk om juist te mocken voor gebruik in unit tests. Daar is echter via een custom model binder nog een vrij elegante oplossing voor te maken.

Het stijgt je nu misschien wel even boven het hoofd, maar het is slim om deze dingen toch even te bestuderen voor je losbrandt. Je hebt er later in het proces veel profijt van als je nu (dwz zo vroeg mogelijk in het leer-/bouwproces) er al over na hebt gedacht.

Bedankt hier kan ik vast al wat mee doen
Maar kan ik in die User ook andere zaken in stoppen? Bv e-mail, userid,...

[ Voor 12% gewijzigd door frye op 28-06-2012 11:20 ]

[frye]

Schop, iemand die het weet?

[Megamind]

Ik zou zeggen, ga even wat tutorials volgens zoals de MVC music store of nerddinner, daar komen heel veel dingen terug.

[xPhantom]

Het punt met

code:

User.Identity.Name

is dat je de gebruikersnaam krijgt... als TS dat wilt is het geen punt natuurlijk. Anders is het handig om een kort stukje code te schrijven die via linq de volledige naam uit de database haalt en die laat zien.

Je zou dus met een partial view die je in je user info bar laat renderen, gewoon de naam kunnen tonen..