HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

Unable to see embedded 3.3 forum with jsConnect SSO when 'private communities' enabled

Hi. I've just installed a fresh copy of Vanilla 3.3 within the SSL vhost of an existing custom ERP system (i.e. common domain) in order to embed it within that private system. In order to avoid problems of clashing CSS and JS libraries, I've used Vanilla's excellent advanced-embed feature with jsConnect for SSO. After finding this help with a connection issue > https://github.com/vanilla/jsConnectPHP/issues/20, I was very pleased to get everything working as expected - slick and seamless operation and SSO between ERP and forum 👍️

However, because I don't want anyone accessing the forum directly, I enabled 'Private Communities' and now the forum doesn't show at all in the embedded iframe! (no JS console errors)

I'm assuming that the forum is now hidden to the ERP user at the point of the SSO handshake but can't believe that this hasn't been dealt with before - I can't be the first to want to make an embedded SSO forum private! Before posting a shed-load of config and set-up information, does it sound like I'm missing something glaringly obvious? Is there a config parameter or switch that I need to enable? Any help gratefully received 😀

Tagged:

Comments

  • Options

    Without replicating your exact setup, the problem is hard to debug. Can you check which page/route is shown in the embedded iframe?

    As a temporary measure you could also assign custom permissions to all categories so only registered users can access them, emulating a private community.

  • Options
    edited August 2020

    Thanks for taking the time to respond #Bleistivt - I may well end up using your permissions suggestion, but I'd rather try and get to the bottom of this in case whatever is wrong bites me from another direction.

    I noticed that even when I accessed the forum directly (i.e. without the iframe), when I signed out, the page went blank (requiring the use of /entry/password to get back in). I concluded that this might be something to do with having configured Sign In and Sign Out URLs (which I want) in the jsConnect dashboard, and that the plugin might be trying to send me somewhere else (note that the configured routes work fine when not in 'private' mode). So as a temporary measure I removed the Sign In and Sign Out URLs. Now when I logged out of the standalone forum, I got the sign-in page complete with 'Sign in with XYZ' option, which was very encouraging.

    I still couldn't get in via the embedded iframe, but I now got this console error:

    [snip] /forum/api/v2/locales/en/translations.js?h=3.3 net::ERR_ABORTED 403 (Forbidden)

    ...together with lots of warnings from DevTools (note that the /forum/ directory is missing from the URL):

    DevTools failed to load SourceMap: Could not load content for [snip] /api/v2/sourcemaps/forum/sourcemaps/owkmw/de918abab1d1a0fe3f38: HTTP error: status code 404

    There is no /api/ directory in my codebase, and neither could I find one on GitHub!

    I googled the 403 path and found this > https://open.vanillaforums.com/discussion/37359/issue-with-locale-api-translations-js-404 which suggests that this could be down to server configuration. Our server config is very specific to our clustered platform, so I repeated the OP's quick-fix and created the missing JS target with a blank file. That fixed the console error but I still got a blank iframe and now I got this console error repeated (twice):

    "Uncaught TypeError: window.parent.callRemote is not a function"

    The function that is throwing the error is:

     // Call a remote function in the parent.
     Vanilla.parent.callRemote = function(func, args, success, failure) {
       window.parent.callRemote(func, args, success, failure);
     };
    

    Finally I have an error message that looks like it should help me, but I'm new to Vanilla and whilst I'm a seasoned dev, JavaScript has never been my strong point! So it's suggesting that a JS file is not being loaded that should be, but I'm not sure where to go next. This is my iframe parent page code, which works perfectly when the forum is not in 'private' mode:

      <script src="/forum/js/easyXDM/easyXDM.min.js"></script>
      <script src="/forum/js/vanilla.embed.js"></script>
      <script>
       var vanillaEmbed = new Vanilla.embed({
        container: 'embedVanilla',
        autoStart: true,
        root: '/forum/',
        initialPath: '/sso',
        sso: '[snip]'
       });
      </script>
    

    Any ideas anyone?

    [Edit] thinking... if the api translation files aren't being found when in 'private' mode, then presumably or possibly neither are the JS files that contain the callRemote function! And if this is the case then why is this only an issue when the forum is in 'private' mode?

  • Options
    edited August 2020

    I'm sorry #Bleistivt ; you asked about the page/route shown in the embedded iframe. With the Sign In and Sign Out URLs in play, it is:

    https:// [snip] /forum/container.html?url=/forum/sso?sso= [snip] &xdm_e=https:// [snip] /interface/forum&xdm_c=default4348&xdm_p=4

    Interestingly, when I look at the content of the blank iframe, I can see all the html code for a different (default on log-in) page from my ERP system, but it does not show because the iframe has been assigned with a visibility of 'hidden'.

    So next I removed the Sign In and Sign Out URLs, then tried to get back in via the iframe. I'm still getting the "window.parent.callRemote is not a function" error but when I study the iframe code I can again see non-visible content. But this time it is the forum Sign-In page complete with 'Sign in with XYZ' option.

    So the iframe is calling the correct content from the forum, it's just not signing in automatically nor making the iframe content visible. And that is probably because it is not finding a JS file from an api call that is not being added somewhere along the line ...maybe.

    And most importantly of all: this is only an issue when the forum is in 'private' mode.

    Edit: It makes no difference whether the .htaccess #RewriteBase parameter is / or /forum

  • Options

    And most importantly of all: this is only an issue when the forum is in 'private' mode.

    The only place where jsconnect acts differently when PrivateCommunity is enabled is here (no uniqueID coming from the jsconnect "authenticate" request):


  • Options

    That function is probably the root-cause of the problem then, but I'm now out of time to pursue this any further. I hate to admit defeat but JS has never been my strong point and the whole advance-embedded/jsConnect mechanism is obviously quite complex - too complex for me to delve into at the moment, given that there are many ways to workaround this.

    I would be interested to know if anyone else who has securely embedded their 3.3 vanilla instance with jsConnect is able to run in 'private communities' mode, but I guess that security/privacy is not going to be such an issue with most vanilla deployments, which are publicly viewable.

    Anyway, because I've located vanilla within my ERP vhost it is within 'session range' of the ERP application. This means that I have been able to add a simple session var check via a bootstrap.before.php file which, as the name suggests, allows me to check for a logged-in ERP user and exit, if necessary, before vanilla is bootstrapped.

    Thanks for trying to help me out - you're very kind :)

  • Options
    wm1wm1 New
    edited September 2020

    I have "Enable Private Communities" enabled using jsConnect + Connect registration only (no manual user registration allowed), using self-hosted v=2 jsconnect (non-JWT) protocol. It seems to work fine.

    I do not have container.html or easyXDM imports - my only line is a script src for js/embed.js.



  • Options

    Thanks #wm1. I suspect the bug or configuration issue (whichever) is related to the 'advanced' embed set-up. I've now created a private community by other means, but I suspect this issue will be an issue for someone else before too long.

Sign In or Register to comment.