Store Locator Plus for WordPress Forums Store Locator Plus Firewall – http vs https

This topic contains 4 replies, has 2 voices, and was last updated by  Cici 3 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #59233

    kenklein
    Participant

    We are having a critical issue with our Store Locator Plus functionality on this page:
    smokeybones.com/locations

    The problem is related to a firewall we use (“Sucuri”) that automatically translates http:// requests to https:// on the server side but it appears that the Plugin being behind the firewall thinks it can send http:// requests to find the map locations but this results in a mixed http/https that then apparently causes the Google mapping functionality to consider the page insecure and cease functionality.

    We located a line of code in the plugin where the re-routing could possibly be forced to be https: and thus allow the map to work but we were hoping that you all perhaps had a solution/patch that might not break on future updates and so forth (as opposed to our ‘hack’ idea) to handle situations where a firewall may be causing the effect above —

    plugins/store-locator-le/js/admin-locations-tab.js: full_url = ( _this.boolean.site_import_protocol ? ‘https://’ : ‘http://’ ) + _this.site_import_url + ‘/wp-json/store-locator-plus/v2/locations’;

    If you can help us with this critical issue as soon as possible we would appreciate it very much —
    Thank you,

    Relevant page: smokeybones.com/locations

    Store Locator Plus®:5.0.5

    Experience:5.0.1

    Power:5.0.1

    Site URL:http://smokeybones.com

    This Info Cached:1557964213

    Network Active:No

    WordPress Version:5.0.4

    PHP Version:5.6.40

    MySQL Version:5.5.62

    PHP Limit:256M

    WordPress General Limit:40M

    WordPress Admin Limit:256M

    PHP Peak RAM:61 MB

    PHP Post Max Size:8M

    #59240

    Cici
    Keymaster

    SLP has nothing to do with the http to https issue., The developer uses Sucuri extensively and there is absolutely no reason to have to hack anything in order to allow a plugin to communicate with the outside world if your configuration and network server is set up correctly. .  If you have HTTPS on your server it should automatically route to/from i.e. — if someone goes to http:// blahyah.com it will auto-redirect

    either way, if you are having to hack,  you have not configured  your network and web app firewall (sucuri) properly

    article the developer has written that mentions Sucuri and caching

    As far as our plugin , the only thing that would be effected regarding the search  functionality would be if using Chrome  you will not have advantage of the Location sensor aware.

    Mixed content , as far as this topic, I am  not sure how you are even getting that error since your site is http not https .  so it does not appear to have been migrated

    I would do some research especially on the WordPress support to find out how to properly configure and migrate, or check out the Sucuri blog

     

    #59242

    kenklein
    Participant

    Thanks so much for your reply —
    Regarding https – since we were having problems with the locations page working under https, we made changes on Sucuri to always redirect to http. I just now modified the settings so that it will redirect to http, so you can test to see the problem that we are having. (We’ll leave it that way until 5PM Eastern Time in case you’re able to take a look but then we’ll have to revert it at 5PM for now to make sure it functions over the weekend.)

    The SSL cert is at Sucuri. So, when a user browses to smokeybones.com using https, that communication is secure. But the communication from Sucuri to the web server *is not secure* – all communication from Sucuri to the web server is over http. My theory is that since the communication from Sucuri is not secure, that the API rest_url that is generated assumes it should be http, and that code with the http gets cached at Sucuri. But, when a user hits the site using https and the rest_url is http, the user has now entered a mixed-mode state, and the API call will fail.

    For you to see this in action, navigate to https://smokeybones.com/locations/ (it should no longer redirect you to http). Enter something that should give results (“Miami” normally gives results) — and you’ll get the following:
    Could not locate this address. Please try a different location.
    undefined

    The response back from the API call is
    {“code”:”rest_forbidden”,”message”:”Sorry, you are not allowed to do that.”,”data”:{“status”:401}}

    If you switch the page to http://smokeybones.com/locations/ – you’ll see that Miami will return results.

    Please let us know if you are able to take a look before 5PM Eastern Time today (Friday) with our current firewall settings — and thanks again so much for your help

    #59243

    kenklein
    Participant

    Hi — Hope I catch you in time — I’ve been informed that this project is now on hold so we wanted to let you know we don’t need an answer on this currently, and didn’t want to waste your time following up, so please disregard request above.

    Thanks for your help. If we need more info later we’ll check back, regards

    #59247

    Cici
    Keymaster

    Ok, No Problem. As mentioned this is not a plugin issue.  The developer has written a few articles about the rest api but the later versions/updates  of WP fixed the issue., what you are describing is preventing  communication, but  this is out of my realm and will require vetting by your team with the help of the WordPress developer  community  at large and Sucuri.

    I will close the topic

Viewing 5 posts - 1 through 5 (of 5 total)

The topic ‘Firewall – http vs https’ is closed to new replies.