November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Sounds strange, can you post a version of the full code that still redirects to start page but shouldn't?
When I tested it worked fine redirecting to /episerver/cms using this test code:
Action:
[HttpPost] public ActionResult TestRedirect() { return Redirect("/episerver/cms"); }
View:
<div> @using (Html.BeginForm("TestRedirect", "Test", FormMethod.Post)) { <button type="submit">Test</button> } </div>
(I'm already logged in when doing this, but the outcome should be the same regardless of when you login the user.)
Here is the full monty.
View:
<div class="modal"> @using (Html.BeginForm("LocalLogin", "CustomLogin", FormMethod.Post)) { @Html.AntiForgeryToken() <ol class="clearfix"> <li> <img src="/util/images/login/DXC_long.svg" alt="logo" class="logo" /> </li> <li> <div class="validation-summary text--error"> @Html.ValidationSummary() </div> </li> <li> @Html.LabelFor(x => x.Username) @Html.TextBoxFor(x => x.Username) </li> <li> @Html.LabelFor(x => x.Password) @Html.PasswordFor(x => x.Password) </li> <li> <input type="submit" value="Log in" class="epi-button-child-item" /> </li> <li> <p class="text--small"> <a "#" onclick="toggleCookieText(); return false;"> When you log in, cookies will be used. </a> </p> <div id="cookieInfoPanel" class="cookie-information"> <p class="text--small"> A cookie containing login information will be sent to your web browser. If you do not want to receive cookies, you will be unable to log into the website. </p> </div> </li> </ol> } </div>
Controller:
namespace A1Digital.Site.Controllers { public class CustomLoginController : Controller { private UISignInManager uiSignInManager = ServiceLocator.Current.GetInstance<UISignInManager>(); private UIUserProvider uiUserProvider = ServiceLocator.Current.GetInstance<UIUserProvider>(); public ActionResult Index() { return View(Global.CustomLoginView); } [HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] [ValidateInput(false)] public ActionResult LocalLogin(CustomLoginViewModel model) { if (ModelState.IsValid) { bool result = uiSignInManager.SignIn(uiUserProvider.Name, model.Username, model.Password); if (result) { return Redirect("/EPiServer/CMS"); } } ModelState.AddModelError("LoginError", "Login failed"); return View(Global.CustomLoginView, model); } } }
Moreover, when taking a look at the network tab in the browsers console, the request points correctly to "/CustomLogin/LocalLogin" with a HTTP Status Code of "302 - Found", but the "Location" header of the response is "/".
If you manually visit "/episerver" after being redirected to "/", is your user considered to be logged in?
Do you have an <authentication>-element in your web.config? If you have one, what does it look like?
Yes, after the user is redirected to "/" he can even see the orange EPiServer menu in the upper right corner and can access the backend.
That's what the <authentication>-element looks like in our web.config:
<authentication mode="None"> </authentication>
Does this happen in a specific environment?
Can you test what happens if you use the basic redirect code I posted above? You can first login (for example through "/Util/Login.aspx").
So far I have only tested this on my local machine (we have the DXC subscription).
Interestingly your code works. When clicking the "Test" button, I get redirected to /episerver/cms.
probably late to the party and not sure if it's related, but looking at `EPiServer.Cms.UI.AspNetIdentity.ApplicationUISignInManager<TUser>` you can see that it does redirect on its own.
public override bool SignIn(string providerName, string userName, string password) { string returnUrl = this.GetReturnUrl(); if (!this._signInManager().SignIn(userName, password, returnUrl)) return false; this.Redirect(returnUrl); return true; }
and there is custom redirect method in that manager:
protected virtual void Redirect(string returnUrl) { HttpContext current = HttpContext.Current; if (current == null) return; if (string.IsNullOrWhiteSpace(returnUrl)) return; try { current.Response.Redirect(VirtualPathUtility.ToAbsolute(returnUrl), false); current.ApplicationInstance.CompleteRequest(); current.Response.End(); } catch (ThreadAbortException ex) { } }
NB! note `currect.Response.End()` method..
and redirect url is standard aspnet query string (if present) - "?ReturnUrl=..". you can give it a try and test login process with custom redirect url just to make sure that this signin manager is not messing things up.
I just tried to login with the ReturnUrl parameter like "/CustomLogin?ReturnUrl=%2Fepiserver%2Fcms" but again simply got redirected to "/" .
can you add what request is being posted to the controller (can capture network traffic in dev tools for instance)?
the login page is really a custom one (and just looks like built-in) or you use default epi login page?
Yes, this is actually a custom login page and just looks like the OOTB login page (for now ^^).
ok, and custom login page form containing action with "ReturnUrl" query string?
@using (Html.BeginForm("LocalLogin", "CustomLogin", new { ReturnUrl = "http://takemehome.com" }, FormMethod.Post))
?
Hello again Patrick!
I started setting up a project of my own which makes use of ASP.NET Identity. After I set it up I decided to take a proper look at solving this issue.
It was indeed the absence of ReturnUrl that caused it. The solution to this that I came up with can be found here:
The solution doesn't require you to set a ReturnUrl at all (if you don't want to) and it also enables you to use your OWIN configuration file to specify a redirect location when users sign in.
Hope this helps!
Thanks a lot @Valdis for pointing us in the right direction!
Hi folks,
We have a custom login page in place, quite similar to this one here.
We would like to redirect users to the backend, to be precise to "/EPiServer/CMS".
Currently, the code in the CustomLoginController looks like this:
So we tried different things here to actually redirect to the backend but whatever we do we always get redirected to the StartPage / index page. Things we have tried:
Any ideas what we are doing wrong?
Best regards,
Patrick