I’ve noticed that when authenticated user logged in, the browser’s payload shows the password in plain text. Any way to get over that and have some kind of hash value instead.
You are on /users/view/<ID> so my guess would be you just created a user via the add method, right?
So you submitted to the add action, it creates the user and it then should redirect to the view page (without any form data since a redirect will cause a GET request, not a POST)
In the end it would be nice if you could give us code snippets how we can reproduce that.
No, the user is coming from login page.
When authenticated successfully. I fetch the identity from request and then redirect user to their profile page ‘users/view/{id}’.
The code 
I’ve checked add action. It does the same as you guessed.
You seem to misunderstand how logins work here.
The clear text password is being sent from the client to the server to then be hashed and compared to the hash in the database. The hashing happens on the server side, not the client side. This of course means the password is sent in “clear text” but we expect you to have HTTPS on your live server anyway so that all data via HTTP is encrypted and can’t be sniffed. This is standard and totally fine.
All you see in the client is the 302 redirect (your return $this->redirect($redirect); line) which of course contains the $_POST data from the client (and therefore the clear text password).
Like you can see here
The browser just shows you the redirect HTTP request as well. The “real” HTML is coming from your 2nd request in your list named 12 because you are on the /users/view/12 page.
1 Like
Of course the hash happens in the server-side.
I was just thinking about that ‘clear text’ as serious issue especially when people use the same browser. But as you clarified HTTPS will solve the problem… Many thanks 