Support Forum

sure, this is only for verifying the problem

@dave & mateo: does the redirect fix the problem with your installations also?

-----
regards from germany
..::[Zikula Application Framework]::.. ..::[SEO-Blog]::.. ..::[CMS Sicherheit]::..

JørnWildt

Lars: now I am not able to use fjeldgruppen.dk due to the redirect which always lands me on http://www.fjeldgruppen.dk. I assume this is what you wanted.

The result is that I never get a cookie for fjeldgruppen.dk (without http://www.) - and now it works, I am unable to reproduce the error, and I never send more than one cookie.

So this "works for me" - but it does not solve the issue when you have multiple websites on multiple sub-domains.

Jorn you are right here.

1. Some browsers do the job fine with cookies from www and non www (Safari beta is VERY picky with that, you might be able to easy reproduce bugs like that with rthe little crappy apple thingie)

2. The redirect is a hotfix.

3. I guess the donain is not handled correctyl/the same way in the API functions. I dont know it, since i am not in the source anymore. Matter of fact is that id start checking here. I guess some function mod_magics away the prefixing domain, causing this kind of error. The explanation why you dont see the bug in any brwoser is in 1.

As irrelevant as this is , on .764 I experienced a strange cookies related login issue and my workaround was to activate the sessions for anonymous users (crappy workaround). It was on a multisite as well

eckerl

JørnWildt

Lars: now I am not able to use fjeldgruppen.dk due to the redirect which always lands me on http://www.fjeldgruppen.dk. I assume this is what you wanted.

The result is that I never get a cookie for fjeldgruppen.dk (without http://www.) - and now it works, I am unable to reproduce the error, and I never send more than one cookie.

So this "works for me" - but it does not solve the issue when you have multiple websites on multiple sub-domains.

Jorn you are right here.

1. Some browsers do the job fine with cookies from www and non www (Safari beta is VERY picky with that, you might be able to easy reproduce bugs like that with rthe little crappy apple thingie)

2. The redirect is a hotfix.

3. I guess the donain is not handled correctyl/the same way in the API functions. I dont know it, since i am not in the source anymore. Matter of fact is that id start checking here. I guess some function mod_magics away the prefixing domain, causing this kind of error. The explanation why you dont see the bug in any brwoser is in 1.

For whatever reason the issue has been intermittent...please test with the lastest SVN. I seem to be in the clear... now..

-----
David Pahl
Zikula Support Team

Quote

For whatever reason the issue has been intermittent...please test with the lastest SVN. I seem to be in the clear... now..

Please hold on a few hours more - the current fix from Mateo is also only a hotfix (in my personal opinion).

Okay, there is a new fix in SVN now.

Here is an explanation of the problem:

Okay, now I also figured out why the login fails ... the point is that it does in fact *not* fail - it only looks so! Confused? Hang on ...

The shortest sequence to failure I have found is:

(clear cookies)

[read PNSID = short for POSTNUKESID = session ID name]

1) Get fg.dk (returns cookie PNSID=A)
2) Get http://www.fg.dk (sends PNSID=A) - (session ID "A" is recognized, so no need to return a new one)
3) Login http://www.fg.dk (sends PNSID=A) APPARENTLY FAILS - (returns PNSID=B)
4) Get http://www.fg.dk (sends PNSID=A + PNSID=B) - (returns PNSID=C)
5) Get http://www.fg.dk (sends PNSID=A + PNSID=C) - (returns PNSID=D)

Here is what happen (with some new explanations):

1) PostNuke sees a new anonymous user and creates a session entry "A" for it.

2) PostNuke sees the same user as before so nothing happen.

3) The login does NOT fail - in fact it worked perfectly, so PostNuke decides to kill session "A" and create a new session "B" for the logged in user. For this reason it issues the new cookie "B". Then it redirects immediately to step 4.

Status: Session "A" (belonging to fg.dk) is destroyed. Session "B" (belonging to http://www.fg.dk) is LOGGED IN.

4) The browser does not know that session "A" was destroyed, so it happily sends cookies "PNSID=A" and "PNSID=B" for both domains. Now PHP selects the first cookie, so PostNuke sees session "PNSID=A" - but this was destroyed and so it is unkown, and PostNuke creates a new session "PNSID=C". Now the used is no longer logged in, because "C" is fresh and "B" (which is still logged in) is not visible to PostNuke/PHP.

5) PHP selects the first cookie, so PostNuke sees session "PNSID=A" - but this was destroyed and so it is unkown, and PostNuke creates a new session "D".

... and so on ...

Conclusion: the browser sends two session IDs - one that is destroyed and one that is logged in. Unfortunately the logged in session is ignored because PHP chooses the destroyed session ID.

/Jørn

Here is the solution: add the number of dots in the hostname to the session ID name. So we now have:

fg.dk => POSTNUKESID1
community.fg.dk => POSTNUKESID2
http://www.community.fg.dk => POSTNUKESID3

This uses the session ID name configuration from the admin panel - with the smallest possible addition.

I could have chosen to add an MD5 of the hostname, but chose not to since the above is simpler and the net-result would be the same. The numbers 1,2,3 is in fact a (very simple, but satisfying) checksum just like MD5.

There is no use of the cookie's Domain parameter, so I have removed Mateos fix.

This will force all sub-domains and the top-domain to use separate cookies. So no Single Sign On. That will have to wait for a later version where we add some settings to the MultiSite administration. It seems like Drak has some ideas.

Hopefully this will satisfy everybody.

/Jørn

Seems like a solution that should always work Jorn.

Just for interest and perhaps cosideration it seems that, according to RFC 2109 http://www.ietf.../rfc2109.txt a session domain must always start with a dot. This would mean the domain for fg.dk would be .fg.dk and for http://www.fg.dk it should also be .fg.dk.

This would mean sessions for fg.dk and http://www.fg.dk would use the same sessions domain and thus the same cookie. Of course subdomains would have a different session domain in the form of .sub.fg.dk.



edited by: dits, Apr 02, 2008 - 10:07 AM

I've added that domain_cookie logic but seems that didn't work in the Jorn's server... pretty weird, because as you said dits, the "wildcard cookie domain" .fg.dk should work for both cases, but Jorn didn't confirm if that cookie domain was defined Ok or not... i don't know...


-----
- Mateo T. -
Mis principios... son mis fines

I've added similar logic before in .76x for a different purpose, SearchBlox search-engine refused to login without it. In pnSessionSetup I had this:

Code

// BR START
    // The SearchBlox spider needs to find a cookie_domain starting with a . (RFC 2109)
    if ($remoteaddr = 'aaa.bbb.ccc.ddd') {
        $domain = preg_replace('/^[^.]+/','',$host);
        ini_set('session.cookie_domain', $domain);
    }
// BR END 

You've probably done something similar? What happened, or did not happen, on Jorn's server?

Mi patch was:

Code

Index: includes/pnobjlib/SessionUtil.class.php
===================================================================
--- includes/pnobjlib/SessionUtil.class.php (revisión: 24115)
+++ includes/pnobjlib/SessionUtil.class.php (copia de trabajo)
@@ -75,9 +75,22 @@
         // if (pnConfigGetVar('intranet') == false) {
         // Cookie path
         ini_set('session.cookie_path', $path);
+
         // Cookie domain
-        // only needed for multi-server multisites - adapt as needed
-        // ini_set('session.cookie_domain', $domain);
+        $cookie_domain = pnGetHost();
+        // Strip leading periods and the www.
+        $cookie_domain = ltrim($cookie_domain, '.');
+        if (strpos($cookie_domain, 'www.') === 0) {
+            $cookie_domain = substr($cookie_domain, 4);
+        }
+        // strip the port number
+        $cookie_domain = explode(':', $cookie_domain);
+        // Per RFC 2109, cookie domains must contain at least one dot other than the
+        // first. For hosts such as 'localhost' or IP Addresses we don't set a cookie domain.
+        $cookie_domain = '.'. $cookie_domain[0];
+        if (count(explode('.', $cookie_domain)) > 2 && !is_numeric(str_replace('.', '', $cookie_domain))) {
+            ini_set('session.cookie_domain', $cookie_domain);
+        }
         // }
 
         // Garbage collection 

It removes the "www" and generates the "wildcard" .domain.tld or .subdomain.domain.tld ...
again, i don't know why it doesn't work in the Jorn's server...

P/S: Anyways, for different needs,
the cookie_domain should be adapted for SSO sites or other requirements.



edited by: nestormateo, Apr 02, 2008 - 08:06 PM
-----
- Mateo T. -
Mis principios... son mis fines

Mateo: sorry, it *did* work, I just got a bit confused about that part during the debugging frenzy.

I appreciate all the effort that has been put forth on this matter! Thanks to everyone!

-----
David Pahl
Zikula Support Team

Implementing this patch will mean existing sessions (logged in user) will have to log in on an upgrade to .8. For most sites this should not be a problem. For some (specifically one that I'm managing ) it will.

JørnWildt

Mateo: sorry, it *did* work, I just got a bit confused about that part during the debugging frenzy.

i know that Jorn. I was almost crazy trying to find an explanation for my cookies' behavior. Anyways, i think that my patch needs to include the cookie_path in the _SessionUtil__Destroy function of SessionUtil...

@dits: So, currently the SVN code changes the session-name and doesn't define the cookie_domain, that affects you? Do you have an "users always logged-in" site?

-----
- Mateo T. -
Mis principios... son mis fines