[OJS] Session problems in multijournal installations with custom base_url's

[ajnyga]

Hi, this applies to all latest versions of OJS, because I think the code for sessions has been the same for a while.

Scenario:

User is logged in from the site level at site.com. A new session with domain .site.com is created.

User moves to a subdomain journal (custom base_url). The user no longer appears to be logged in and a second session is created with domain .journalname.site.com.

User logs in from the journal and can enter the dashboard successfully.

User logs out.

The session .journalname.site.com is updated to reflect that the user has logged out. The session with domain .site.com still shows that the user is logged in.

Problem: if the user now tries to log in from the journal she can not anymore. After logging in the session is updated to reflect that she has logged in, but OJS does not allow her to access the dashboard. Also the user navigation menu shows the login and register links.

What I am wondering is that do we need to initiate new cookies for each subdomain, or could we just always use the main domain in the cookie? For example .site.com.

[ajnyga]

@ctgraham would really like to hear your view on this, I think you have dealt with similar issues before.

@asmecher my suggestion is that we allow a config override here: https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L41

The problem with getServerHost seems to be that it returns the main domain site.com on the site level but returns the journal subdomain name.site.com on the context level. So you always end up with two cookies with two domains.

I believe that this section of code here https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L65-L71 should deal with that issue? But it does not. What comes to mind is that we upgraded to PHP7 recently and these problems started to show up. Could there be something in the sessions management code that changed from 5->7?

In any case, I hardcoded the site.com value here https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L41 and it works fine now.
When I go to the site level I get a session and stay logged in when I move to the subdomain journal. Also, if I first visit a subdomain journal with no existing sessions I still get just one cookie and stay logged in if I move to the site level. I can also log out from either of those places.

So do you see any problems arising if we would allow site admins to define an override cookie domain value from config.inc.php.

Would this work with cases where each journal has it's own domain altogether?

[ctgraham]

My earlier investigation of this was largely based on divergent behavior of Internet Explorer:
http://wayback.archive-it.org/7100/20180509142027/https://pkp.sfu.ca/bugzilla/show_bug.cgi?id=8843

My original proposal suggested propagating up a session to the parent domain, if sessions on both the current domain and parent domain were found to belong to the same OJS installation.

I wasn't able to reproduce the issue you describe in my development site with the following configuration:

• Chrome 72.0.3626.121
• Apache/2.2.15
• PHP 5.6.40
• OJS 3.1.1

Perhaps this is a change from PHP 5 to PHP 7, as you suggested? I'm in the process of building a PHP7 dev environment for OJS 3.1.2, but it is unlikely I'll be able to report on results this week due to holiday and vacation time.

[ajnyga]

I have a feeling that PHP7 could be involved because I do not think these problems occured earlier and we have been using subdomains for 3 years now.

[ajnyga]

If you log in on the site level and move on to a subdomain context, do you get two session cookies?

[ctgraham]

Not in my testing as above. Each domain has a single distinct cookie. What browser are you testing with?

[ajnyga]

Ok, so just to be clear, my problem seems to be happening because each domain get a distinct cookie.

I log in in the site level > I get site.com cookie.
I move to a subdomain journal > I get new journalname.site.com cookie and have to login again
I log out in from the context > the site.com cookie stays logged in and the journalname.site.com is logged out, but something is then preventing me from logging in again to the context.

I figured that the best solution would be if the site.com cookie would work also in journalname.site.com so that there would be just one cookie all the time?

[ctgraham]

the best solution would be if the site.com cookie would work also in journalname.site.com so that there would be just one cookie all the time?

I concur. This was the intent of my PR from 2014, though it appears it is not actually working that way, even in PHP5.

[ajnyga]

do you see any potential problems in allowing a config override that would just set a certain domain?
Just thinking how it all would work if some journal has a completely own domain.

[ctgraham]

I generally take a very negative view of variables in config.inc.php. We ought to be able to handle this appropriately directly within the session management code. If we can't, however, the use of a config.inc.php variable might be a solution. I really strongly lean toward fixing the code. The config.inc.php override would be problematic if any base_url[] did not exist in that "forced" cookie domain.

[ajnyga]

The reason why I think a config is the only solution is because the main site may be installed on a subdomain address itself.

If you have an organisation atorganisation.com and they have OJS at ojs.organisation.com and subdomain journal at journal1.ojs.organisation.com. How do we know that we want to use ojs.organisation.com in the cookie domain? Or do you think we could just use organisation.com?

My idea was that the setting would be voluntary. Just something that would override this https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L41 if it was defined. Otherwise we would just use getServerHost.

[ctgraham]

I don't think we want to send the cookie to all of organisation.com for security purposes.

If access starts at ojs.organisation.com, and if the cookie for ojs.organisation.com is sent to journal.ojs.organisation.com, it should be trivial for the code to use the parent's cookie.

If access starts at journal.ojs.organisation.com, an additional login will be required if accessing ojs.organisation.com, but the next access to journal.ojs.organisation.com can delete the journal.ojs.organisation.com cookie in favor of the ojs.organisation.com cookie.

[ajnyga]

hmm, ok. I will see if I can turn that into a pr.

but I do not like the fact you need to log in again in some cases...

[ajnyga]

Your suggestion can be reached by adding

		if (isset($this->userSession))
			$domain = $this->userSession->getDomain();
		else
			$domain = ini_get('session.cookie_domain');

here: https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L218

But I still think that allowing a domain to be set from config.inc.php would be a cleaner solution.

[ajnyga]

The reason why you end up with multiple cookies is that setcookie here: https://github.com/pkp/pkp-lib/blob/master/classes/session/SessionManager.inc.php#L227

is called with different domain names. Namely the main domain and the subdomains when you go to a context.

So maybe alternatively we could always delete the old cookie before setting the new one?

[ajnyga]

@ctgraham not seeing many problems with that solution #4595 (comment)

If you access the site from the site level, you end up with a single cookie. If you access from the subdomain journal, you end up with two and have to log in again on site level. Just like you described. But compared with the original situation that is not that bad.

Also I believe that this solution would work the best with installations that have separate domains for journals? I think that my original solution with a fixed cookie domain name would not work at all.

@asmecher would really appreciate your comments here as well. This has become a fairly big issue at least for us. But of course understand that you have other things you are busy with as well.