@tbvgl Helped me identify that the root fix should be in Wappler’s middelware so I’m summoning @patrick@George
Core problem:
I login on maindomain.com, siteSecurity2.auth cookie is set on .maindomain.com and I’m logged in in this session, I see cookie: siteSecurityId: 1 in the redis session.
I navigate to sub.maindomain.com - it automatically logs me in (thanks to the .auth cookie)
I logout on sub.maindomain.com - it removes the .auth cookie and my session is not logged in in redis (no siteSecurityId)
I go to maindomain.com and i’m still logged in in the session, BUT the .auth cookie is gone
I go to sub.maindomain.com and I’m NOT logged in. Because the .auth cookie is missing and I was logged out of the session in step 3.
Desired: when logging out on a subdomain, it logs me out of the session on the main domain and any other subdomains
Extra info:
Using nodejs and redis
The cookie options at the security provider are set to .maindomain.com
i may be wrong here but i recalled there is also a session variable set which holds the user id during that server session.
I think Wappler checks for a security session value before checking for the cookie so if the session is not destroyed the login may reman valid
So if your security provider is called “siteSecurity2”, on login there is also a server session variable started called “$_SESSION.siteSecurity2Id”
you may want to check that this session variable is destroyed when logging out from a subdomain as this may be the cause
Yes, there should be a Security Logout step. Only erasing the cookie is not acceptable (I don’t know anything about handling cookies in Wappler though)
I assume you want to share the sessions also between the domains, just like the security provider.
Create in the folder lib/config a file user_config.json. This can be used to override config options, Wappler will not touch this file.
In this file you can configure how the session cookies are set, default it will be for the current domain. You could probably use the same settings as for the security cookie, depending on how and where you use the sessions.
@patrick creating a file user_config.json in lib/config does not get picked up by the auth login script. It still sets the domain as undefined or defined as whatever was added via Wappler security provider UI.
Adjusting the constructor for the AuthProvider in provider.js by using an ENV variable directly works
Sorry, seems I gave the wrong folder. All the user files should go in the app folder and not in the lib. So the correct folder for the user_config.json is the app/config folder where also the config.json generated by Wappler is located.
to user_config.json in app/config and then logging in on http://app.localhost:3000 sets the security cookie Domain to app.localhost while it should be .app.localhost.
it sets it correctly if I define it via ENV variable instead inside provider.js
this.cookieOpts = {
domain: process.env.COOKIE_DOMAIN,
httpOnly: true,
maxAge: (opts.expires || 30) * 24 * 60 * 60 * 1000, // from days to ms
path: opts.path || '/',
secure: !!opts.secure,
sameSite: opts.sameSite || 'Strict',
signed: true
};
@patrick
We paid Tobias a lot of money to figure this out for us.
His solution works.
Can we have a fix so Wappler won’t prompt us to override the provider.js and we have to keep making sure we don’t overwrite the file?
Is there a similar way we can set the session cookie on the main domain? Currently it sets the .auth cookie on the entered domain. But the session cookie is set on the subdomain we’re on.
I think we can update the security provider code to accept dynamic options so that you can set the cookie domain with an expression to get the environment variable instead of having to edit the library file.
The cookieOpts in the provide.js file is for the remember me cookie and not for the session. The session cookie is configured using the config.json file. I’ve tested it by setting the options in the user_config.json and it works for me.
You can also use environment variables in the config like: