Hiding parameters in URL MVC4 - asp.net-mvc-4

Question

I am developing an application, using VS 2010 and MVC4(Razor). I am stuck with the Url parameters. I am able to implement LogIn method. Once I validate the user I want him to redirect to other page, so I am using
RedirectToAction("UserAction","User",new{userID = "",password=""});
But the issue is as RedirectToAction usses HTTTPGet all the url parameters userID and the password are visible.
How do I invoke RedirectToAction with HTTPPost.
Any help will be highly appreciated.
Here is my Login.cshtml
#using (Html.BeginForm("SignIn", "Login", FormMethod.Post))
{
#Html.AntiForgeryToken()
#Html.ValidationSummary(true)
<fieldset>
<legend>Log in Form</legend>
<ol>
<li>
#Html.LabelFor(m => m.UserName)
#Html.TextBoxFor(m => m.UserName, new { id = "UserName" })
#Html.ValidationMessageFor(m => m.UserName)
</li>
<li>
#Html.LabelFor(m => m.Password)
#Html.PasswordFor(m => m.Password, new { id = "Password" })
#Html.ValidationMessageFor(m => m.Password)
</li>
</ol>
<input type="submit" value="Log in"/>
</fieldset>
}
And here is my Login Controller
bool IsValidUser = ValidateEachUser(oLoginModel.
UserName,oLoginModel.Password);
if (IsValidUser)
return (RedirectToAction("UserDetails", "User", new { userID = userID,
password =
password }));
else
return View("Login");
Thanx and Regards

Answer 1

The solution is like #anaximander mentioned. Upon successful log in, save the user details in an encrypted cookie (e.g. FormsAuthenticationTicket) that gets submitted with every request, then you can verify the credentials on every action call by decrypting the cookie. If you want to implement your own verification protocol you can even implement your own AuthorizeAttribute and either decorate all the methods with it manually or register it globally in Global.asax (inside RegisterGlobalFilters).
You should really think though about whether you really need to keep the password. The fact that the user request contains your encrypted cookie can be used as an indication that the user has been authenticated. If you want to make sure that the user is authorized to run a certain action method, the user id should be enough. This would save you having to store the password and recheck it at every call before checking if the user is authorized to run the method.

Answer 2

TempData - is answer on your question:
TempData["userID "] = "some";
TempData["password"] = "some";
RedirectToAction("UserAction","User");
This might work. If it doesn't add a comment :)

Answer 3

if you want to a method HTTPPOST put the head of method like:
[HTTPPOST]
RedirectToAction(your parameters){}

Answer 4

This started as a couple of comments, but I think there's now enough to be worth making it an answer.
The best way to identify the user is probably with an encrypted cookie containing an identifying token - NOT their password - so that you can check who the user is. The cookie is sent with every request, silently, with no extra work. If you need it, you can check it. An action filter is a neat way to do this.
ASP.NET MVC 4 has a perfectly good Forms auth system built in that works exactly like this. There's plenty of tutorials out there; this one is a decent example. It's pretty straightforward to implement, and you can override a few parts of the workings to use your own database, your own user model, etc. The user provides credentials, you check them, and the system gives the user a cookie. The [Authorize] filter checks for that cookie and uses it to decide whether the user is allowed to do what they're trying to do. There's also scope for roles-based authorisation, but if you don't need that you can ignore it.
Whatever you do, you do NOT want to be keeping the user's password ANYWHERE. If you end up using your own database to store users, don't keep the password in there - look up something like bcrypt, use it to hash the password with a randomised salt, and store that along with the salt value. To check a user's login, you hash what they provided with the salt you have, and see if the output matches the hash you saved. The shorter the time that password remains in the system, the narrower the window where an attacker could get hold of it.