Uderzam w tę stronę od wielu godzin i jestem zdziwiony. Tworzę żądanie ajax ajax do kontrolera MVC 5, próbując automatycznie zalogować określonego, zdefiniowanego "super" użytkownika. W metodzie sterownika próbuję programowo ustawić HttpContext.Current.User i uwierzytelnić, aby superużytkownik mógł pominąć proces ręcznego logowania. Konsensus w tej sprawie wydaje się być tutaj, który zaimplementowałem:. Uwierzytelnianie za pomocą formularzy .net - ręczne ustawianie HttpContext.Current.User nie działa w niestandardowy AuthorizeAttribute
setting HttpContext.Current.User
Wydaje się to działać, dopóki nie spróbuję wyświetlić żadnych innych metod kontrolera z niestandardowym AuthorizeAttribute. Metoda
Kontroler:
[HttpPost]
[AllowAnonymous]
public ActionResult Login(string username)
{
string password = ConfigurationManager.AppSettings["Pass"];
User user = service.Login(username, password);
var name = FormsAuthentication.FormsCookieName;
var cookie = Response.Cookies[name];
if (cookie != null)
{
var ticket = FormsAuthentication.Decrypt(cookie.Value);
if (ticket != null && !ticket.Expired)
{
string[] roles = (ticket.UserData as string ?? "").Split(',');
System.Web.HttpContext.Current.User = new GenericPrincipal(new FormsIdentity(ticket), roles);
}
}
//...processing result
return Json(result);
}
Sposób service.Login powyżej tworzy plik cookie:
FormsAuthentication.SetAuthCookie(cookieValue, false);
choć jestem ustawienie użytkownika, który ma swoją tożsamość i IsAuthenticated jest prawdziwe, filterContext .HttpContext.User poniżej nie jest tym samym użytkownikiem. Jest w zasadzie pusty, jakby nigdy nie był przypisany i nie jest uwierzytelniony.
public override void OnAuthorization(AuthorizationContext filterContext)
{
string[] userDetails = filterContext.HttpContext.User.Identity.Name.Split(char.Parse("|"));
}
Najbliższa poczta mogłem znaleźć tutaj: IsAuthenticated works on browser - but not with Air client!
Jednak poprawka na to było już na miejscu dla mnie:
<authentication mode="Forms">
<forms cookieless="UseCookies" timeout="60" loginUrl="~/Account/Login" />
</authentication>
Co mi brakuje, aby AuthorizationContext. Użytkownik pasuje do HttpContext.Current.User, który uwierzytelniam w kontrolerze?
UPDATE:
Zdaję sobie sprawę, że trzeba ustawić przekierowanie cookie prawidłowo, po prostu nie jestem w stanie wykonać tę pracę zdalnie, za pośrednictwem wywołania AJAX. Oto, jak wygląda skrypt w witrynie A podczas wykonywania metody kontrolera na stronie B. To przekierowanie nie ustawia sesji. Nadal nie jest obecny podczas uwierzytelniania użytkownika przy użyciu kolejnej metody kontrolera. Przekierowuje mnie z powrotem do widoku logowania.
function remoteLogin(id) {
$.ajax({
url: "/MyController/RemoteLogin",
type: "POST",
dataType: "json",
data: { "id": id }
}).done(function (data) {
if (data) {
if (data.user) {
var user = data.user;
$.ajax({
url: "http://siteB.xyz/Account/Login",
type: "POST",
dataType: "json",
data: { "username": user.username, "password": user.password }
}).done(function (data) {
if (data) {
window.location.href = "http://siteB.xyz/Next"
} else {
alert("Fail.");
}
}).fail(function (data) {
alert("Fail.");
});
} else {
alert("Fail.");
}
}
}).fail(function (data) {
alert("Fail.");
});
}
To właśnie znalazłem się, rozglądając się - to, czego szukam, jest sposobem na zrobienie tego w kontekście tego, co próbuję - zdalnego logowania. Na przykład ustawienie "location.href" w przypadku sukcesu w moim skrypcie nie ma znaczenia. Potrzebuję sposobu, aby zrobić to, co opisujesz, zdalnie, przez wywołanie ajax. –
Potwierdzone! To, co zrobiłem (i jest to wątpliwe), to napisanie pliku cookie z nazwą użytkownika/hasłem po stronie App A, a następnie otworzenie nowego okna ze skryptu, na sukces wywołania ajax. W aplikacji B czytam i niszczę tymczasowy plik cookie, wykonuję logowanie, a następnie przekierowuję do uwierzytelnionego widoku. Wszystko wydaje się działać. Zaktualizuje mój OP o szczegóły, później. –