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

SSO Sign In & Register Embedded Issue (Version 3.0.2)

I've got Vanilla 3.0.2 SSO working well in an embedded mode.

Using the "Sign In" and "Register" buttons on the Vanilla forum site jump to my site's custom sign in and register pages. This is as designed (and desired!).

The issue is those two custom pages appear within the embedded frame hosting the Vanilla forum site.

To see the issue first hand, head over to https://eventtruly.com/forum#/discussions and select the "Sign In" button. You'll see the custom sign in page embedded in a frame in the larger site. Doesn't look great.

I found a resolution for this issue described in the following older post on this site (section 2.1):

and made a stab at following those instructions but came up unsuccessful.

Any one know if there are any newer guides that can help me have my custom "Sign In" and "Register" pages not be embedded in the Vanilla frame? Thanks.


  • Looks good here. That button sends me here


  • R_JR_J Ex-Fanboy Munich Admin

    When I click on the register link I see that double-embedding, too.

    I have no solution for that, but one observation and one workaround (a good one, I'd say)

    First the observation: you are referencing an old discussion. There is a some official documentation about embedding and single sign on available:



    Now to the workaround: when looking at your page I see the login and register links in the upper menu bar and then, additionally, the sign in and register links of Vanilla. Those two links aren't really needed and somehow confusing anyway, I'd say.

    If you add the following line to your conf/config.php, the guest module will not be displayed any more:


    If you want to have some kind of message for guests, you can either use Vanillas Messages or the Pockets plugin.

  • Ah yes, I see it now.

    The inner is an iframe and thus loads as such. You can remove or even hide the two links as R_J said. In config or by using CSS.

    If for some strange reason you still need them, then you can use JavaScript to load the iframe into the parent when either of those links is clicked.

    In fact all you need is a target="_parent" attribute. Set it in Vanilla or via JS, topically:

    <a href="/Vanilla/entry/signin?Target=discussions" class="Button Primary" rel="nofollow" target="_parent">Sign In</a>
    <a href="/Vanilla/entry/register?Target=discussions" class="Button ApplyButton" rel="nofollow" target="_parent">Register</a>
  • Thank you both for these suggestions. I will implement later today.

  • icefieldicefield New
    edited September 2019

    To wrap up, here's is what I ended up doing in case others might have a similar case:

    1) Added $Configuration['Garden']['Modules']['ShowGuestModule'] = false; to conf/config.php to remove "Sign In" and "Register" buttons from guest module area, since my site has similar options in navigation title bar (as per R_J's suggestion).

    2) Modified library/SmartPlugins/function.signinout_link.php and function.signin_link.php by adding target="_parent" to <a ref...> tag (as per donshakespeare's suggestion). This modified the "Sign In" link that appears in the set of options just above the breadcrumb panel to open sign in page in parent rather than in embedded frame.

  • Problem is you just modified a core file. When you update Vanilla the changes will disappear.

    Hence my suggestion to use JavaScript to cosmetically alter that piece of code, that is if at all it is still needed after you disabled it in config.php

  • icefieldicefield New
    edited September 2019

    Understood, don. Thanks.

    Disabling in config.php removed the "Sign in" and "Register" buttons. An additional "Sign in" link is still present in the links just above the breadcrumb. Poked around for a config option to turn that off, and didn't readily see any option that would handle that second sign in. Thus, the modification of the two php core files. Without modifying those, clicking the second sign in link results in the double-embedding. Adding the target option that you mention avoids that issue.

    I'm open to cleaner suggestions. Perhaps target="_parent" might be added to those two files in the core delivery of Vanilla - though someone more familiar with that code than me can most certainly point out some downsides to that addition.

  • One last take on this: besides setting $Configuration['Garden']['Modules']['ShowGuestModule'] = false;, I ended up not modifying the two core files in library/SmartyPlugin, and instead added the following JS code to the EmbedFriendly default.master.tpl theme file. The code was added just prior to the closing </html> tag:

            jQuery(document).ready( function(e) {
                let vanillaSignInSignOutLinks = $('a[href^="/Vanilla/entry/"]');
                if (vanillaSignInSignOutLinks) {
                    vanillaSignInSignOutLinks.attr("target", "_parent");

  • So, you will continue to find that Vanilla is a pretty tasty flavour for forum, and I encourage you to continue to use it and investigate it.

    In addition, I recommend that no forum user should use any prepackaged inbuilt theme. I mean, clone one of those themes you think you like, and start hacking and plotting, it's fun, it's knowledge no one can take from you, it's easily sustainable if done right.

    Oh, and users should have at least their own hand-made themehook or basic plugin running, nothing major or big, just to keep the hands-on alive.

    If you have already done all this, then awesome.

    To answer your question, I am assuming you are using the embed-friendly theme (hopefully your own clone), remove or replace {signinout_link}

    Go to themes/EmbedFriendly/views/default.master.tpl

            <div class="Row">
                <strong class="SiteTitle"><a href="{link path="/"}">{logo}</a></strong>
                <ul class="SiteMenu">
                    {signinout_link} <-***BLAST THIS THING *****************

    Perhaps target="_parent" might be added to those two files in the core delivery of Vanilla - though someone more familiar with that code than me can most certainly point out some downsides to that addition

    Not everyone will be using the embed thing the same way.

  • Ah, I see you responded before I hit submit.... awesome solution code.

    And thanks. I learnt about {literal} today. I have been using silly workarounds ever since :)


  • R_JR_J Ex-Fanboy Munich Admin

    "core" files normally means any files that are shipped with a Vanilla installation. That includes the EmbedFriendly theme, too. Therefore I would recommend to use the Pockets plugin to insert that JavaScript snippet

  • ^^ yup! hopefully he cloned that EmbedFriendly template already to be his own.

  • One more go round on this based on R_J and donshakespeare's feedback:

    Removed my prior JavaScript addition to default.master.tpl core them file (as mentioned a few posts back). Copied Embed-Friendly theme to custom EventTruly theme.

    Enabled Pockets plugin, and created following pocket:

    One issue unrelated to any of the above that I had to work around: None of my Vanilla Dashboard edits are saved to config.php. I have to edit that file directly to get the changes to stick (e.g., enabling Pockets plug-in and specifying active theme name). Any guidance on this specific issue is appreciated. (Maybe I should have posted this Dashboard issue in a new thread.)

  • None of my Vanilla Dashboard edits are saved to config.php. I have to edit that file directly to get the changes to stick (e.g., enabling Pockets plug-in and specifying active theme name).

    Could something have happened to the file permissions for config.php ?

    I think 0775 is the standard

  • Hey Kaspar - thought that might may have been the issue, but rechecked permission, group, and ownership and all are proper values.

    If I make a change via the Dashboard --> Settings, for example toggling on an additional plugin, the toggle turns on, but if I refresh the page the toggle is off again. The number of enabled plugins at the top of the page doesn't change either, and no updates are written to config.php.

    Permission on that file is 755.

    Not sure what is causing this issue.

  • R_JR_J Ex-Fanboy Munich Admin

    If your changes do not "stick" to the config.php, the config.php cannot be written. 755 permission might not be enough based on the user and the group rights of your config folder. Try to make it 775 as per Kaspars suggestion

Sign In or Register to comment.