OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums OroCRM OroCRM – Installation/Technical Issues or Problems No Token in TokenStorage error after update to 3.1.13

This topic contains 2 replies, has 1 voice, and was last updated by  Dylan 3 months, 4 weeks ago.

  • Creator
  • #40533


    I ran into a problem after upgrading OroCRM, from release 3.1.2 to 3.1.13
    When I’m trying to log in, it seems that the login is successfull but then I get WARNING in prod.log that there is no Token in TokenStorage, and the site keeps refreshing.
    It is only happening when I’m trying to access the site with https:// but it works totally fine when using http://
    I have not changed any security settings so I am wondering if there have been any changes to some security mechanics that could have caused this issue.
    thanks you for any help

Viewing 2 replies - 1 through 2 (of 2 total)
  • Author
  • #40539


    It turns out that I’m having the same problem as described in this post ( https://forum.oroinc.com/orocrm/orocrm-installationtechnical-issues-or-problems/topic/orocrm-3.1.6-admin-panel-401-error-on-apirestlatestnavigationitemspinbar/page/2 ) , the “X-CSRF-Header” is missing on the first /pinbar request. However as far as I can tell it doesn’t have anything to do with apache or nginx configuration, I tried manually sending the header and dumping it in index.php and the header was there. On top of that, the previous version of OroCRM worked fine on that same server with same proxy configuration. For some reason the XMLHttpRequest doesn’t contain the header when I accessing via https, but I can’t figure out why. I rerun the “oro:assets:install” command thinking maybe its a problem in jquery but with no result.
    I would appreciate any help



    Update: RESOLVED
    So after a lot and lot of debugging and going through ORO and Symfony code I found what the problem was. For some reason the variable $_SERVER[‘HTTPS’] wasn’t set even when coming from https. Therefore the symfony csrf component decided that the request wasn’t secure and set the token into the non-secure cookie, but the ORO jquery that sets the “X-CSRF-Header” header obviously has a different check whether the request is secure and therefore was trying to read the non-existent secure csrf cookie. It is probably cause by the proxy my server is behind. I solved the issue by putting this piece of code in index.php

    This should be pretty universal to all possible proxy configurations. The only thing I don’t understand how the application was working before the update to 3.1.13 since there have been no changes to the proxy or the Symfony csrf component, but whatever I’m just glad I got it to work.

    • This reply was modified 3 months, 4 weeks ago by  Dylan.
Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

You will be redirected to [title]. Would you like to continue?

Yes No