Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Flavio Spezi 128 posts 314 karma points
    Jun 06, 2015 @ 16:23
    Flavio Spezi
    0

    Backend go crash when navigating Frontend in same browser

    When a user navigate in Frontend and Backend with the same browser, the Backend go down.
    It is possible to look that there is an error in browser console:

    GET http://localhost:8123/umbraco/backoffice/UmbracoApi/Authentication/GetRemainingTimeoutSeconds 417 (Invalid token)

    The version of Umbraco is 7.2.5. I look this issue from some back versions.

    The issue can be temporary solved with a refresh of backoffice page. But when the user requires a new call in frontend (or Ajax call), the backoffice go down another time.

    How can I solve the issue definitivelly, without using 2 different browser?

    Note

    With a Google search, maybe I found a reason of the issue: I think that it is the result of Umbraco anti-XSRF attach.

  • Jan Skovgaard 11280 posts 23678 karma points MVP 10x admin c-trib
    Jun 08, 2015 @ 12:01
    Jan Skovgaard
    0

    Hi Flavio

    Is the user logged in both in the backoffice and on a member section on the public facing website? Or is the user just logged into the backoffice browsing the public facing website without being logged into the website?...Hope this makes sense...:)

    /Jan

  • Flavio Spezi 128 posts 314 karma points
    Jun 08, 2015 @ 12:20
    Flavio Spezi
    0

    Hi Jan, the issue exists with and without user logged in Frontend.

    Note: the website uses some cookie.

  • Joseph 59 posts 140 karma points
    Jul 01, 2015 @ 00:56
    Joseph
    0

    We've tracked down the reason for this problem: the front-end was creating a cookie that had a name that had an 'invalid' character in it (in my case it was the opening and closing brackets). Interesting that the backoffice would fail as it did in this scenario but it's easy enough in this case to change the cookie name so that it all works now.

  • Flavio Spezi 128 posts 314 karma points
    Jul 01, 2015 @ 10:13
    Flavio Spezi
    0

    In my case I am using right cookie name format.

    The website uses Ajax to refresh some front-end widget data.
    There are two:

    • the first is used to refresh data every 2 seconds via HTTP GET method (I will call it AjaxA).
    • the second is used to refresh data every 10 seconds via HTTP POST (i will call it AjaxB).

    To test this behavior I have open the front-end and back-end with the same browser, in 2 browser tabstrip pages.

    When administrator open a Node in BackOffice, the XSRF-TOKEN and XSRF-V cookies changes value.
    In the same time, the AjaxA continue to works properly in frontend: the method send cookies to server; the server do not returns any cookie.
    Administrator continue to open others Node in BackOffice. After 10 seconds the BackOffice do not works. The browser console shows this error:
    Failed to load resource: the server responded with a status of 417 (Invalid token).
    Looking in frontend, the AjaxB is called: the method send the same cookies/values of AjaxA, but server returns newest XSRF-TOKEN and XSRF-V values.

    The only solution that I found is to refresh the Backoffice page. But it is not confortable.

  • Matthew Kirschner 323 posts 611 karma points
    Oct 20, 2015 @ 13:44
    Matthew Kirschner
    0

    @Flavio,

    Did you ever find a solution for this issue?

  • Flavio Spezi 128 posts 314 karma points
    Oct 22, 2015 @ 08:47
    Flavio Spezi
    0

    Hi @Mattew, yes, I solved my issue.

    My front-end code call API to refresh widget data. One of theese API method was declared with SetAngularAntiForgeryTokens attribute. This attribute change XSRF-TOKEN and XSRF-V cookies.
    The solution is to remove the attribute.

  • Matthew Kirschner 323 posts 611 karma points
    Oct 22, 2015 @ 12:54
    Matthew Kirschner
    0

    Thank you, Flavio. That is very confusing since I'm not using that attribute anywhere in my front-end code.

    We are making liberal use of MVC HtmlHelper's AntiForgeryToken on our front-end forms. I wonder if this might have a similar effect.

  • Flavio Spezi 128 posts 314 karma points
    Oct 22, 2015 @ 17:38
    Flavio Spezi
    0

    I think that it is important to not update values of XSRF-TOKEN and XSRF-V cookies.
    Because they are used by Umbraco back-office.

  • Matthew Kirschner 323 posts 611 karma points
    Oct 22, 2015 @ 18:38
    Matthew Kirschner
    0

    I think I found out what was going on.

    In order to allow a WebApi controller to access Session variables, I had updated the codebehind for Global.asax to set the SessionStateBehavior to Required:

    protected void Application_PostAuthorizeRequest()
    {
        HttpContext.Current.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Required);
    }
    

    Once I removed the above code, Umbraco was finally able to create the XSRF tokens again.

  • Flavio Spezi 128 posts 314 karma points
    Oct 23, 2015 @ 07:42
    Flavio Spezi
    0

    Well, fantastic!

Please Sign in or register to post replies

Write your reply to:

Draft