C# MVC how statements work

Asked

Viewed 120 times

1

I have the code below, and to call the Session that stores the user data, only once I want to put it in the controller statement.

Doubt

The variable usuarioLogado is by request or it may happen that user X calls the controller and in between user Y calls the same controller, and usuarioLogado information exchange, where should be reading user X, step to have user Y.

Code

public class AppRequisitoController : Controller
{
    string controller = "AppRequisito";
    UsuarioLogadoDTO usuarioLogado = Services.UsuarioService.SessaoUsuarioLogado();

    private void Listagem(Conexao db)
    {   
        var repAppRequisito = new AppRequisitoRepositorio(db);
        ViewBag.ListaAppRequisito = repAppRequisito.ComboBox(usuarioLogado);
    }

User Session

public static UsuarioLogadoDTO SessaoUsuarioLogado()
{
    return HttpContext.Current.Session[Constantes.sessaoUsuarioLogado] as UsuarioLogadoDTO;
}
  • What does Services.UsuarioService.SessaoUsuarioLogado();?

  • @I edited the question.

  • I don’t think it’s a good idea for you to wear Session to get the user logged in. Better use authentication provider information. Session is not consistent 100% of the time in application without states like those written in ASP.NET MVC. This code will stop working quite frequently.

  • @Ciganomorrisonmendez would have some example of authentication provider?

  • Membership, Identity... I don’t know what you’re wearing.

  • @Gypsy I’m using Membership

Show 1 more comment

2 answers

2

Interactions in web applications can be Stateless or Statefull, that is, it does not maintain application status or keeps track of the state of interactions. In requests Stateless states are maintained on the customer, through cookies or otherwise, always in an encrypted form.

A Session on the other hand keeps the state on the server different from the cookie, so Statefull, it works as follows, your application creates a key that references the data that is temporarily kept on the server. Then it sends a cookie or other form of authentication to the client, which references the data stored on the server.

Then there would be no case of the user receiving data from another user’s session because it is referenced by this unique key.

  • 1

    It’s a little weird what you said. Sessions is one thing. Cookies is another. Sessions does admit a transient state, maintained on a server. Cookies is a feature in which information is recorded in client and has nothing to do with states. She can help recreate a state, but that’s not mandatory.

  • Yeah, I didn’t say that Session and Cookie are the same thing, they’re different. Session management can be implemented through cookies since the key to referencing the data on the server has to be on the client. I don’t know how I can make that position clearer, which part you found confusing so I can improve the answer?

  • 1

    The second sentence. It seems they are the same.

  • 1

    One last thing (it’s pretty good already): Sessions are not stateless. There is simply no state maintenance, other than Cookies, that this yes can be considered partially stateless because you can recreate the state by the application code.

1

It’s always by request. This doesn’t just apply to ASP.NET MVC, this is how a web application works.

Basically, no server-side state is maintained. That’s why you use strategies like cookies to simulate this kind of thing, the cookies are sent in all requests and handled on the server.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.