sub domain issues regarding SSO logout and get logged in user access_token on main domain.

ab3v

We have setup forum as sub domain with our main site and also we have configured SSO seamlessly with our main site everything's is working fine then i have discovered some issues.

1) I want my user to logout from forum as soon as user gets logout from main system, earlier we use to do that with cookies when our forum was not setup on sub domain and we are accessing it from sub folder. Thing is that we use to get cookie set by vanilla on user login under our main domain and destroying it user get logout from forum. But now we are unable to access Cookies set by vanilla on our main domain, what i have noticed that now vanilla is setting cookies with sub domain, earlier it use to set cookies with our main domain. We know that cookies are not shared between domains unless you explicitly tell them to stored under main domain. so i have configured $Configuration['Garden']['Cookie']['Domain'] = 'mysite.com'; in config file hoping that it would resolve the problem but eventually problem get worse and now user can not even get login through SSO which was working fine earlier, Cookies are not even get set under sub domain which was working, before we configured cookie domain in config. Removing this configuration everything's works fine except logout from main website. so my question is why vanilla is not settings cookie under main domain and is their any other approach we can try?

2) we want logged in user conversations on our main website so we turn our heads into forum API we have got what we wanted from conversations API controller but the thing is that we have to pass access_token of logged in user for authentication which we have created from edit profile in forum and it's working fine but we do not find any centralised solution for accessing API. what i have mean with centralised is that we need to make access_token for every user in forum, so it's headache we cannot tell each user to generate access_token so that we can pass their access_token for authentication and somehow if it gets possible, how we can get that access_token in our main website so that we can pass to API for authentication and is their any other solution we can work on or ?

My configuration are as follow

Vanilla Version: 2.6.3

Main Domain Url:
www.mysite.com

Forum sub domain Url:
www.forums.mysite.com

Api Version : 2

Any help would be appreciated. Thanks

R_J

https://docs.vanillaforums.com/developer/apiv2/authentication/#issuing-access-tokens

Right now, addons are expected to issue access tokens as part of their specific single-sign-on mechanism.

You need to create a Vanilla plugin which would be able to create such a token. The tokens are stored with a name called "Type" in the database. You can issue/check for a valid token on every successful sign in:

public function entryController_afterSignIn_handler($sender, $args) {
    $accessTokenModel = new AccessTokenModel();
    // Try to find a valid token.
    $accessToken = $accessTokenModel->getWhere(
        [
            'UserID' => $args['UserID'], // The ID of the user to issue a token for
            'DateExpires >=' => Gdn_Format::toDateTime(), // Only still valid tokens
            'Type' => 'YourCustomSSO' // Your token identifier
        ]
    )->firstRow(DATASET_TYPE_ARRAY);
    if ($accessToken == []) {
        // Issue new token if needed.
        $token = $accessTokenModel->issue(
            $args['UserID'],
            '2 Months',
            'YourCustomSSO'
        );
    } else {
        // If token exists, sign with expiry date.
        $token = $accessTokenModel->signToken(
            $accessToken['Token'],
            $accessToken['DateExpires']
        );
    }
    // Save signed token to table UserMeta so that you can fetch it from another script or think of other methods to pass it.
    // UserModel::setMeta($args['UserID'], ['YourCustomSSOToken' => $token]);
}

You need to get access to that signed token in any way. I just saved it to the UserMeta table in the example above. That is a bad and not secure way because it is similar to storing the password in the database. But on the other hand, that is the drawback of every API token...

ab3v

Thanks for quick reply R_J. I will analyze and get back to you on this.