Covering OroCRM topics, including community updates and company announcements.  Subscribe

Forums OroCRM OroCRM – Installation/Technical Issues or Problems setup using a HTTPS reverse proxy

This topic contains 15 replies, has 5 voices, and was last updated by  cljk 5 months, 3 weeks ago.

  • Creator
  • #55974



    I’m trying to run orocrm behind a TLS reverse proxy.
    “Almost” everything is fine except two things :

    • whatever locale I’m using, it tries to access <locale>.js over http, resulting in Firefox blocking the display. The only workaround is to “disable protection” so all calls load. After the file is retrieved once, other calls are made over https
    • I have absolutely no clue of the websocket settings, according the following setup :
      – reverse proxy is listening on <public_ip>:443
      – internal apache server is listening to

    Any help appreciated (especially for the websocket thing).


Viewing 15 replies - 1 through 15 (of 15 total)
  • Author
  • #55975


    For the <locale>.js, same thing happens with Safari (latest, 9.1).
    JS developper log says :

    [Warning] [blocked] The page at was not allowed to run insecure content from (require.js, line 1900)

    I tried to change routing.yml to

    but it did not helped.


    Could you please provide us with the version of Apache and reverse-proxy server,
    And if it’s possible – the parts of the configuration files of these services.
    Additional information is required to investigate this issue.



    Here it is.
    Apache is running 2.2.22 on a Debian 7.
    Reverse-proxy SSL offloading is made by haproxy 1.6.4.

    Apache virtual host is pretty classic :

    haproxy settings are classic to :

    An X-Forwarded-For header is added to the request from haproxy to apache.

    Thanks for your help,


    Please see our part of the haproxy config below (it’s default one without any customization):

    Please re-check the “option forwardfor” is configured on haptoxy side. You mentioned about it, however I cannot see it in your part of the configuration file
    Also please make sure that “timeout tunnel” option is set to some high value.



    Thanks for your feedback.
    The forwardfor option is set in the default section

    For the web socket settings, it means that it cannot be configured so the WS traffic is redirected from the HTTPS frontend to the WS backend ?
    Could you send your relevant part of the parameters.yml for the websocket ?

    Also there is still an issue with the loading of the localization JS : it does try to retrieve <local>.js over HTTP which the browser blocks as HSTS is enabled.

    [Warning] [blocked] The page at was not allowed to run insecure content from (oro.min.js, line 1061)

    Is there a way to solve this ?




    From Chrome error message :



    OK. No more issues with the <locale>.js after modifying routing.yml this way :

    However, I’d like to know if websocket bind/frontend/backend settings could allow all traffic to be diverted by the reverse proxy without opening another port.


    We’re glad to hear that you solved the issue with the <locale>.js

    You would like to proxy all the traffic e.g. http and websocket via only one port 443, right ?
    Seems it’s not possible to perform it correctly. The application is designed to have two ports one for http traffic and another for websocket.



    For my knowledge, what are those 3 websocket settings then ?


    > For my knowledge, what are those 3 websocket settings then ?
    Could you clarify your question?

    Usually we configure only the parameters below for websocket and leave default values for others :



    I am wondering what is the use of the 3 pairs of settings from parameters.yml

    The haproxy and the apache web server are running on the same machine thus haproxy cannot bind to the same port as the websocket server. That’s why I guess I should use websocket_bind on an used port and declare frontend_host and frontend_port to what the enduser sees. I don’t know what backend port could be made for.



    Sort of works with the change to routing.yml but when I use non-standard port (8443) the problem returns with the port number missing for the en.js file. Also get issues with redirects to and from the login page portnumber is there but wrong scheme (http)….

    Looking at the page source I see the base url config of requireJS picks up the port but not the https scheme:

    <script type="text/javascript">
    var require = (function(){
    var r=function(c){m(r.c,c)};r.c={};function m(a,b){
    for (var i in b)b[i]!=null&&b[i].toString()==='[object Object]'?m(a[i]||(a[i]={}),b[i]):a[i]=b[i]}
    return r;
    baseUrl: "\/bundles",
    urlArgs: 'version=ee4ee2b6'
    config: {
    'oroui/js/app': {
    baseUrl: "http:\/\/",
    headerId: "x-oro-hash-navigation",

    Code for this is in UIBundle/Resources/views/requirejs.config.js.twig

    baseUrl: {{ app.request.getSchemeAndHttpHost()|json_encode|raw }},

    and the translation picks up the scheme but not the port….

    shim: { 'oro/translations': {
    deps: ['orotranslation/js/translator', 'translator'],
    init: function(__) {
    return __;}}},
    map: { '*': { 'orotranslation/js/translator': 'oro/translations'},
    'oro/translations': {
    'orotranslation/js/translator': 'orotranslation/js/translator' }},
    paths: {
    'oro/translations': 'https\x3A\x2F\x2F127.0.0.1\x2Fjs\x2Ftranslation\x2Fen'
    config: {
    'orotranslation/js/translator': {
    'debugTranslator': false

    Source in TranslationBundle/Resources/views/requirejs.config.js.twig

    paths: {
    'oro/translations': '{{ url('oro_translation_jstranslation')[0:-3] }}'

    Any suggestion on how to convince both instances to create ?




    Ahh… in nginx setup don’t use

    fastcgi_param HTTPS off;

    but turn it on…..



    This was a helpful thread. We wanted to post another solution for a very similar setup.
    Our system setup was Cloud Flare HTTPS reverse proxy back over HTTP connections to OROCrm server.

    1. Symphony’s getSchemeAndHttpHost is based upon trusted proxy list. It only matches if the connection to it was HTTP or not (which it will not be). See Symphony Code.
    2. We are unable to set the routing.yml ‘s schemes: [https]. This setting does not work because the Cloud Flare to OroCRM Server is HTTP and forcing to HTTPS will cause an infinite redirect.

    Solution here was to enable trusted proxies in app/config/config.yml as in here Symphony Load balancer Document here. This way getSchemeAndHttpHost picks the forwarded Scheme and host.



    I had a similar issue….

    I installed OroCRM on an internal Apache behind a public reverse proxy. Several forms were rendered with wrong absolute URLs (why that?) and my proxy could not intercept/rewrite them all correctly – especially the AJAX-loaded forms and generated java scripts were problematic.

    I solved it by modifying app.php – inserted…

    where is obviously my private net.
    This should be the correct config for Symphony 2.8 (< 3.x).

    Also the communication schema between reverse proxy and OroCRM-Server was changed from HTTP to HTTPS because several bundles even relied on “app.request.uri” and “app.request.schema”.

    A BIG improvement would be to NOT generate references to absolute pathes or to only use BASE_URL and not schema and server name OR to rely on the specified “application_url” config value… because else what is this for?!

Viewing 15 replies - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.