SO, back to my original thought that this seems to be a bug or a "broken feature". My client, and clients in general, does everything in preview mode and needs to be able to preview/stage membership-based content.
When I test for the condition "inPreviewMode" and if NOT true ( !umbraco.presentation.UmbracoContext.Current.InPreviewMode) ) process the rest of the surface controller security stuff.
That way IsLoggedIn or what other method you are using to establish logged in state doesn't get called.
I'm nearly with the same issue in standard Umbraco permissions, in my case when the Preview Mode opens, it seems the Umbraco is logging some aleatory member, so sometimes the preview mode works and sometimes not, depends if the group of the aleatory logged member has access to the preview page or not.
When using the Public Access feature in Umbraco, the secure page will always display the login page unless the authentication cookie exists (yourAuthCookie). In preview mode, the authentication cookie doesn't get created by the form submission.
I have looked into this further by running ILSpy on the HandleLogin action. This is the method that runs:
public ActionResult HandleLogin([Bind(Prefix = "loginModel")] LoginModel model)
{
if (!base.ModelState.IsValid)
{
return base.CurrentUmbracoPage();
}
if (!base.Members.Login(model.Username, model.Password))
{
base.ModelState.AddModelError("loginModel", "Invalid username or password");
return base.CurrentUmbracoPage();
}
if (!model.RedirectUrl.IsNullOrWhiteSpace())
{
return this.Redirect(model.RedirectUrl);
}
base.TempData["LoginSuccess"] = true;
return base.RedirectToCurrentUmbracoPage();
}
When debugging this the following method returns true.
Within that method the Forms Authentication cookie should be created.
public bool Login(string username, string password)
{
MembershipProvider membersMembershipProvider = MembershipProviderExtensions.GetMembersMembershipProvider();
if (!membersMembershipProvider.ValidateUser(username, password))
{
return false;
}
MembershipUser user = membersMembershipProvider.GetUser(username, true);
if (user == null)
{
LogHelper.Warn<MembershipHelper>("The member validated but then no member was returned with the username " + username, new Func<object>[0]);
return false;
}
FormsAuthentication.SetAuthCookie(user.UserName, true);
return true;
}
The fact that it returns true suggests the cookie WAS created. However something else must be going on after this process because the cookie doesn't make it to the browser.
Does anyone have any ideas on what could be preventing the cookie creation? Also did anyone log this as an issue?
Member login failing in preview mode
We have a simple member-restricted section setup where I do the following check to ensure that a member is logged in:
Any ideas why this login and check wouldn't work in preview mode?
Oh, also, I am using the login controller essentially "out of the box":
Hi Simon
Could you please post the error message too? :) And what exact version of Umbraco 7 are you using?
/Jan
There is no error message. It simply fails to pass the check "(loginStatusModel.IsLoggedIn)"
Umbraco 7.1.4
Getting the same issue. Did you get any further with this?
Same issue here - any joy?
Yes the problem is that preview mode is basically a dump of the XML The context its running in IE membership is not valid.
I think Is tested for it in my view
if (!umbraco.presentation.UmbracoContext.Current.InPreviewMode)
{
Do something
}
Yes the problem is that preview mode is basically a dump of the XML The context its running in, IE. membership, is not valid.
I think I test for it in my view...
if (!umbraco.presentation.UmbracoContext.Current.InPreviewMode)
{
Do something
}
I got that far:
However, it still didnt think I was logged in and presented me with the login form!
SO, back to my original thought that this seems to be a bug or a "broken feature". My client, and clients in general, does everything in preview mode and needs to be able to preview/stage membership-based content.
Is there a fix for this in later versions?
it certainly sounds like a bug - I can't find anything in the Issue tracker - http://issues.umbraco.org/issues
I'd suggest you raise a ticket with Umbraco regarding this - thats the only way it will get fixed.
I think I meant that I didn't apply security when in previewmode, but used the switch as a bypass, filtering out previewmode requests.
ah so how do you disable the security in code?
When I test for the condition "inPreviewMode" and if NOT true ( !umbraco.presentation.UmbracoContext.Current.InPreviewMode) ) process the rest of the surface controller security stuff.
That way IsLoggedIn or what other method you are using to establish logged in state doesn't get called.
Unless I have missed your point completely.
I am not using anything to determine a logged in state - Im using the standard Umbraco permissions to restrict access to certain pages.
However when previewing those those pages the login form is presented and persists even when filling in correctly.
It's like preview mode is completely wiping out any cookies/sessions on every page load.
Hi David,
I'm nearly with the same issue in standard Umbraco permissions, in my case when the Preview Mode opens, it seems the Umbraco is logging some aleatory member, so sometimes the preview mode works and sometimes not, depends if the group of the aleatory logged member has access to the preview page or not.
Did you find some solution?
My Umbraco version is 7.2.5
I am experiencing the same issue in Umbraco 7.2.0.
I am also using the form:
When using the Public Access feature in Umbraco, the secure page will always display the login page unless the authentication cookie exists (yourAuthCookie). In preview mode, the authentication cookie doesn't get created by the form submission.
I have looked into this further by running ILSpy on the HandleLogin action. This is the method that runs:
When debugging this the following method returns true.
Within that method the Forms Authentication cookie should be created.
The fact that it returns true suggests the cookie WAS created. However something else must be going on after this process because the cookie doesn't make it to the browser.
Does anyone have any ideas on what could be preventing the cookie creation? Also did anyone log this as an issue?
FYI the logged issue can be found here:
http://issues.umbraco.org/issue/U4-4219
If anyone else finds this is a problem for them, please up-vote the issue.
is working on a reply...