OroCRM Forums

Covering OroCRM topics, including community updates and company announcements.

Forums 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 6 years, 7 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
    Topic
  • #27134

    igardais
    Participant

    Hi,

    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 127.0.0.1:8080

    Any help appreciated (especially for the websocket thing).

    Regards,
    IG

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

    igardais
    Participant

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

    [Warning] [blocked] The page at https://orocrm.redacted.com/ was not allowed to run insecure content from http://orocrm.redacted.com/js/translation/en.js?version=bf6c70fe. (require.js, line 1900)

    I tried to change routing.yml to

    but it did not helped.

    #27136

    vyaschenko
    Participant

    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.
    Thanks

    #27137

    igardais
    Participant

    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,
    IG

    #27138

    vyaschenko
    Participant

    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.

    #27139

    igardais
    Participant

    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 https://orocrm.example.com/ was not allowed to run insecure content from http://orocrm.example.com/js/translation/en.js?version=7cab5566. (oro.min.js, line 1061)

    Is there a way to solve this ?

    Thanks,
    IG

    #27140

    igardais
    Participant

    From Chrome error message :

    #27141

    igardais
    Participant

    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.

    #27142

    vyaschenko
    Participant

    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.

    #27143

    igardais
    Participant

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

    #27144

    vyaschenko
    Participant

    > 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 :

    #27145

    igardais
    Participant

    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.

    #27146

    ilelie
    Participant

    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;
    }());
    require({
    baseUrl: "\/bundles",
    urlArgs: 'version=ee4ee2b6'
    });
    require({
    config: {
    'oroui/js/app': {
    baseUrl: "http:\/\/127.0.0.1:8443",
    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….

    require({
    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 https://127.0.0.1:8443 ?

    Cheers,

    #27147

    ilelie
    Participant

    Ahh… in nginx setup don’t use

    fastcgi_param HTTPS off;

    but turn it on…..

    #27148

    kirank
    Participant

    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.

    #27149

    cljk
    Participant

    I had a similar issue….
    https://github.com/oroinc/crm/issues/285

    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 192.168.10.0 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)

The forum ‘OroCRM – Installation/Technical Issues or Problems’ is closed to new topics and replies.

Back to top