Adding second language to secure page changes anon user resp

I have many secured pages in my sites that are directly linked from emails or other user notification.  in 3.7 I just had forms auth so the user would be prompted to log in automatically.  Since this doesn't work in 5.0 anymore I added as global asax to redirect 403 responses to a page that asks the user if they want to login (uses the default login/logout control)

This was all working fairly well after I finally got everything configured correctly until it came time to add a second language.  When I do that all the 403 responses turn into a 404 the same as if I had mistyped the url.

This seems like a misconfiguration or a bug.  I have tried different names per language, same names per language it makes no difference.  I built a fresh site out of the Project manager tool and created only a few pages with no other config changes and got the same result so I don't think it is something I am doing that causes it.  Urls for pages that have only one language continue to return a 403 as before, but once you add a second language even deleting the language does not change it back to a 403.  All of the pages work correctly once you are logged in.

I would like to preserve the distinction between a 404 and a 403 because I don't really want to take users back to a login flow if they are already logged in and just found a bad link or mistyped something.

Has anyone else run into this?  or could someone from telerik confirm if this bizarre behavior is intentional?

Hello Bill,

We haven't seen such behavior before and we'll investigate it.
As for the forms authentication it is supported in all Sitefinity versions. So you can try to switch to Forms Authentication and see if the problem appears there too. Here is the documentation about this:

www.sitefinity.com/.../switching-to-forms-authentication


All the best,
Pavel Iliev
the Telerik team

Glad this is not the intended behavior and I could probably send you an example vanilla sitefinitly install that has this problem if you tell me what I need to zip up.

As for forms auth, I should have been more specific.  In 3.7 we were using our own custom forms auth as a full replacement to the sitefinity one.  We burned up around a month trying to make that work in 5.0.  the best we could come up with was overriding some of the sitefinity controls which really does not make is possible to impliment multi-factor or multi-step logins in a reliable way as far as we could tell.  After that we then spent about a month writing all of our auth functionality into a STS and trying to figure out how to get that to integrate into sitefinity correctly.  Another forum member finally posted some example code that got me to a point where I could get this working after several weeks of guessing.  There are still some areas like assigning roles through the sitefinity backend I cannot get to work, but I have the original 9 different ways to log in we had in 3.7 working correctly.  Unless you have instructions on how to get an external forms auth to work with 5.x this is not an option for us.

I will try creating a throw-away forms auth site with multi-lingual pages and see if that makes any difference to the page behavior just for informational purposes and let you know.

UPDATE
Even in forms auth the 403 turns into a 404 when I add a second language so there is no help it toggling that setting.  Also, one of my colleagues has reproduced this in a 5.1 install with pretty much identical results.  The only difference is that he also gets the page saying you have no configured pages because he also localized his homepage.

Hi Bill,

 I am writing on behalf of Pavel Iliev. Thank you for the clarification about your custom forms authentication. If you have any questions or need help about authentication, please open another ticket, so it would be more easy for our support team to handle it.
 As for the issue about 403 and 404 redirects, I investigated what happened. I checked the issue using a fresh 5.0 2500 project. I also checked it in our latest Sitefinity release (5.1 3270). The problem is reproducible only with split translations of the pages. I reproduce it on 5.0 2500 and 5.1 3270 versions. The bug is logged in our bug tracking system.
 I want to note what happens with synchronized translation of the pages. In 5.0 2500 when you open a secure page the response is 403. In 5.1 3270 when you navigate a secure page you are automatically redirected to login screen. This is the difference between old 5.0 2500 version and latest official version 5.1.3270. But for both versions, the bug with split translations of the pages and 404 response, is reproducible.

Thanks for the quick reply. Two clarifications if possible:

5.1 restores the functionality of redirecting to the login flow when the user is anonymous or has insufficient rights without the need of custom error hackery?

We had been using the split translations because they were the default and because it was unclear how to create/update a synchronized translation through the api. If you could provide some insight into the latter we would probably prefer synced translations anyway.

Update: disregard the first question.  I had 5.1.3210 not 5.1.3270 and mis-read.  It works as Miroslava describes in 5.1.3270.  Still would like more info on the synced pages with regards to the API though.

Hi Bill,

Here is a code sample for creating localized pages programmatically:

public static bool CreateLocalizedPage(Guid pageId, string pageName, Guid parentPageId, bool isHomePage, bool showInNavigation, string culture = "en")

  //The CurrentUICulture must be set to the desired culture for the page while translating it.

  //At the end of the method the CurrentUICulture is restored to its original value.

  var cultureInfo = new CultureInfo(culture);

  var currentCulture = Thread.CurrentThread.CurrentUICulture;

  Thread.CurrentThread.CurrentUICulture = cultureInfo;

  var pageDataId = Guid.NewGuid();

  PageManager pageManager = PageManager.GetManager();

  

  PageData pageData = null;

  PageNode pageNode = null;

  var result = false;

  using (new ElevatedModeRegion(pageManager))

 

    var initialPageNode = pageManager.GetPageNodes().Where(n => n.Id == pageId).SingleOrDefault();

    if (initialPageNode != null && LanguageExistsForPage(initialPageNode.Page, cultureInfo))

   

      return result;

   

    result = true;

    if (initialPageNode == null)

   

      var parentId = parentPageId;

      if (parentId == Guid.Empty)

     

        parentId = SiteInitializer.FrontendRootNodeId;

     

      //Create Page

      PageNode parent = pageManager.GetPageNode(parentId);

      pageNode = pageManager.CreatePage(parent, pageId, NodeType.Standard);

      pageData = pageManager.CreatePageData(pageDataId);

      pageData.Culture = Thread.CurrentThread.CurrentCulture.ToString();

      pageData.UiCulture = Thread.CurrentThread.CurrentUICulture.ToString();

      pageNode.Page = pageData;

      pageNode.Name = pageName;

      pageNode.ShowInNavigation = true;

      pageNode.DateCreated = DateTime.UtcNow;

      pageNode.LastModified = DateTime.UtcNow;

   

    else

   

      //TranslatePage

      pageManager.InitializePageLocalizationStrategy(initialPageNode, LocalizationStrategy.Split, false);

      pageNode = GetPageNodeForLanguage(initialPageNode.Page, cultureInfo);

      pageData = pageNode.Page;

      pageData.TranslationInitialized = true;

      pageData.IsAutoCreated = false;

   

    pageNode.UrlName[cultureInfo] = Regex.Replace(pageName.ToLower(), UrlNameCharsToReplace, UrlNameReplaceString);

    pageNode.Description[cultureInfo] = pageName;

    pageNode.Title[cultureInfo] = pageName;

    pageNode.ShowInNavigation = showInNavigation;

    pageData.HtmlTitle[cultureInfo] = pageName;

    pageData.Title[cultureInfo] = pageName;

    pageData.Description[cultureInfo] = pageName;

    pageManager.SaveChanges();

    using (var fluent = App.WorkWith())

   

      var pageIdFacade = fluent.Page(pageId);

      using (new ElevatedModeRegion(pageIdFacade.GetManager()))

     

        if (isHomePage)

       

          pageIdFacade.SetAsHomePage().SaveChanges();

       

        pageIdFacade.Do(p => p.ApprovalWorkflowState = SampleUtilities.ApprovalWorkflowStatePublished; ).IfStandardPage().CheckOut().Publish().SaveChanges();

     

   

 

  Thread.CurrentThread.CurrentUICulture = currentCulture;

  return result;

You may try to pass sync instead of split when you create a page, just change this line of code: 

pageManager.InitializePageLocalizationStrategy(initialPageNode, LocalizationStrategy.Split, false);

If you need all translations of a page to use same widgets, then it is best for you to use sync pages. Once you drop a widget on one of the translations it will appear on the other translations automatically. So it will save you time maintaining and organizing your translations.
In case you need to have different widgets on your translations, then you should use split translations of your pages.

Presently it looks like we will need to use some of both so we are working on the sync version first and will have to return to the other pages once there is a build out that corrects this defect.

I later found this issue from early February: www.telerik.com/.../pits.aspx which sounds similar.  Is this the most appropriate defect to vote for/track for the issue I am encountering?

Hello Bill,

 Yes, you can vote for this issue to be fixed http://www.telerik.com/support/pits.aspx#/details/Issue=10809 . This issue is related to a bug in our bug tracking system and I have updated the bug description with your case. 

I have upgraded one of my projects to 5.1 and even after I delete the translated pages any page that ever had a translation under 5.0 seems to still present with the 5.0 behavior of this defect.

Is there something beyond deleting the split translations that is needed to get a page broken by this in 5.0 to work correctly in 5.1?

Hello Bill,

As Miroslava mentioned, pages in 5.1 will redirect to the login page instead of returning a 403 but the bug with the split pages still exists. Any pages that you had in 5.0 and return 404 will continue to return 404 after the upgrade to 5.1.

Once you set a page's LocalizationStrategy to Split, it will not return to NotSelected or Synced even if you delete the translations of the page and leave just one. You could create a duplicate of that page and use it instead.

We are sorry for the caused inconvenience. Please let me know if I can be of further assistance.

Kind regards,
Marin Atanasov
the Telerik team

since I have deleted the translations can I re-translate them as synced and solve the issue until the split bug is fixed?  or can I manually correct the strategy flag somehow?