Core-Devs need your help: Login Problems

http://noc.postnuke.com/tracker/index.php?func=detail&aid=15902&group_id=5&atid=101
We had several reports of login problems with .8 RC3. Please test your installations with as many browsers as possible. We have no clue at all, if this problem really exists and if it exists, what it is related to.
This is the last big bug before the final release! So if you want a quick final, put all your energy into this!

--
best regards from Kiel, sailing city

Steffen Voss

Member of the Zikula Steering Committee
Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"
The only login problem I've been able to found is related to this topic: http://community.postnuke.com/module-Forum-viewtopic-topic-54177-start-15.htm
If you have the caching enabled, after some logout/login or wrong password, you won't be able to login again until the cache expires (I suppose).

I cannot see any problem without the caching system enabled...
Do we know if the two guys who reported the bug are using PN with or without the caching enabled?

--
Zikula Italia
SimpleGallery
nope, the cache is disabled
currently i have two broken sites and Dave has others...

The problems seems related with the Cookies in some environments...

--
- Mateo T. -
Mis principios... son mis fines
Is it possibile to know more or less the server configuration?

Are you able to reproduce the error?

Do you get any error? What?



edited by: Arthens, Mar 25, 2008 - 06:10 PM

--
Zikula Italia
SimpleGallery
We are looking deep with Chris hildebrandt (slam) about this issue,
by now seems that some servers randomly gets the cookie duplication.

There's no error message, because the session is lost as consequence of the dummy cookie.
I've tested a lot and move some code on SessionUtil to try solutions, but no total luck. I still have a cookie with path "/" that overrides my good cookie that has the path "/PostNuke08/" (when my site is located in a subfolder called /PostNuke08)...

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

Arthens

I cannot see any problem without the caching system enabled...
Do we know if the two guys who reported the bug are using PN with or without the caching enabled?


Well, I can reproduce the error on my server, without caching enabled. Chris, seems very knowledgeable about apache, and while my server is not perfect, it seems adequate.. with no fatal problems. I am not the only one with the issue, of course, but I have many relationships within the PN community so, my server has become the primary focus of the investigation, as it is accessible. But the issue is 'reproducible' and demonstrable, and severe.

I guess since there is a bug report, and it is documented in the forums, we do not really have an idea of how wide spread the issue is.

I will try to contact those who have had login issues, and see if we can gather more data.

If anyone is having this issue, please let us know.



--
David Pahl
Zikula Support Team
David, can you give me access to your server, so that I may try it out and see if I can figure out something? Please mail me: jw at fjeldgruppen dot dk

AmmoDump

Well, I can reproduce the error on my server


Well, How? icon_wink

I mean... is the issue evident or you have to do something particular for reproduce it?
I'd like to reproduce it too for trying to help.

--
Zikula Italia
SimpleGallery
What we got:

I newer SVN (but I first had issues with pre-RC3 SVNs)
A subdomain which contains the PN install.
A cookie is produced for the for the subdomain (expected) and the root domain (not expected). The subdomain cookie is good, as long as not logged out.
Upon trying to login for a second time, we get an auth failure, due to the root cookie.
If the root cookie is deleted, login will pass.
But the root cookie is created again.

This happens on very different versions of apache/php/mysql.

There is some speculation as to why(ish)... but nothing we can confirm.



--
David Pahl
Zikula Support Team
I don't know if it could be related, but everytime I login and logout... I have a cookie created, but never deleted.
After nine login and logout I have nine cookies.

--
Zikula Italia
SimpleGallery
Here is a sample request/response that eventually fails. Comments follow in next post:

Code

=== www.fjeldgruppen.dk ===

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Accept-Language: da
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.fjeldgruppen.dk
Proxy-Connection: Keep-Alive

-------------------------------------------

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 06:34:52 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Set-Cookie: POSTNUKESID=f52ea0591ec76826470dd41bad0ae8a9; expires=Sun, 30 Mar 2008 06:34:52 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=2782817bbf0c617c0d82f105e2342606; expires=Sun, 30 Mar 2008 06:34:52 GMT; path=/
Transfer-Encoding: chunked
Content-Type: text/html

-------------------------------------------

GET /index.php?module=Users%20Manager&func=loginscreen HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Accept-Language: da
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: www.fjeldgruppen.dk
Proxy-Connection: Keep-Alive
Cookie: POSTNUKESID=2782817bbf0c617c0d82f105e2342606;

-------------------------------------------

POST /index.php?module=Users%20Manager&func=login HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Referer: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Accept-Language: da
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Content-Length: 118
Host: www.fjeldgruppen.dk
Pragma: no-cache
Cookie: POSTNUKESID=2782817bbf0c617c0d82f105e2342606;

*** Login OK


=== fjeldgruppen.dk ===

GET /index.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Accept-Language: da
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: fjeldgruppen.dk
Proxy-Connection: Keep-Alive

-------------------------------------------

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 06:38:27 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Set-Cookie: POSTNUKESID=9f38ce4cbdb137a034605d8929deb3aa; expires=Sun, 30 Mar 2008 06:38:27 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=e3627d49925bf3da65f2269067908613; expires=Sun, 30 Mar 2008 06:38:27 GMT; path=/
Transfer-Encoding: chunked
Content-Type: text/html

-------------------------------------------

GET /index.php?module=Users%20Manager&func=loginscreen HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Accept-Language: da
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: fjeldgruppen.dk
Proxy-Connection: Keep-Alive
Cookie: POSTNUKESID=e3627d49925bf3da65f2269067908613

-------------------------------------------

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 06:40:30 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html

-------------------------------------------

POST /index.php?module=Users%20Manager&func=login HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Referer: http://fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Accept-Language: da
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Content-Length: 114
Host: fjeldgruppen.dk
Pragma: no-cache
Cookie: POSTNUKESID=e3627d49925bf3da65f2269067908613

-------------------------------------------

HTTP/1.1 302 Found
Date: Thu, 27 Mar 2008 06:41:56 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=08591407e479d8d09322cd26405b9673; expires=Sun, 30 Mar 2008 06:41:57 GMT; path=/
Location: http://fjeldgruppen.dk/
Transfer-Encoding: chunked
Content-Type: text/html


*** Login OK


=== www.fjeldgruppen.dk ===


GET /index.php?module=Users%20Manager&func=loginscreen HTTP/1.1
Accept: */*
Referer: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager
Accept-Language: da
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Host: www.fjeldgruppen.dk
Pragma: no-cache
Cookie: POSTNUKESID=08591407e479d8d09322cd26405b9673; POSTNUKESID=29201419679d0593689a94ee1884f8d8

-------------------------------------------

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 06:43:45 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=94bc4d9659708b7d2d43ebf1561fe7ab; expires=Sun, 30 Mar 2008 06:43:46 GMT; path=/
Transfer-Encoding: chunked
Content-Type: text/html

-------------------------------------------

POST /index.php?module=Users%20Manager&func=login HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Referer: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Accept-Language: da
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Content-Length: 156
Host: www.fjeldgruppen.dk
Pragma: no-cache
Cookie: POSTNUKESID=08591407e479d8d09322cd26405b9673; POSTNUKESID=94bc4d9659708b7d2d43ebf1561fe7ab

-------------------------------------------

HTTP/1.1 302 Found
Date: Thu, 27 Mar 2008 06:44:58 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=6b9cd5a23024a5befa7a68bde5a55ff6; expires=Sun, 30 Mar 2008 06:44:58 GMT; path=/
Location: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Transfer-Encoding: chunked
Content-Type: text/html


*** Login FAILED


POST /index.php?module=Users%20Manager&func=login HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*
Referer: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Accept-Language: da
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Proxy-Connection: Keep-Alive
Content-Length: 177
Host: www.fjeldgruppen.dk
Pragma: no-cache
Cookie: POSTNUKESID=08591407e479d8d09322cd26405b9673; POSTNUKESID=bd9e67ff8d065ca9111a72c0c730e551

-------------------------------------------

HTTP/1.1 302 Found
Date: Thu, 27 Mar 2008 06:46:28 GMT
Server: Apache/1.3.37 (Unix) FrontPage/5.0.2.2635 PHP/4.4.8
X-Powered-By: PHP/4.4.8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: POSTNUKESID=0322d595274ed40b364a86207b27f1df; expires=Sun, 30 Mar 2008 06:46:28 GMT; path=/
Location: http://www.fjeldgruppen.dk/index.php?module=Users%20Manager&func=loginscreen
Transfer-Encoding: chunked
Content-Type: text/html


*** Login FAILED again
This is what happens:

1) I open www.fjeldgruppen.dk and get one POSTNUKESID cookie issued. Login works.

2) I open fjeldgruppen.dk and get a new POSTNUKESID cookie issued. Login works.

3) Back to www.fjeldgruppen.dk where I now POST TWO POSTNUKESID cookies (one for each domain). Login FAILS.

So apparently either PHP og PostNuke chokes on the fact that there are two POSTNUKESID cookies.

Maybe a solution would be to postfix POSTNUKESID with the sub-domoain? Then the session cookie names would be "POSTNUKESID" and "POSTNUKESID-www".
I cannot always repeat this. I assume this is because the sequece of the two POSTNUKESID cookies changes - sometimes the correct one comes first, some times it does not. But I am not sure about this.
can you redirect all requests to the 'www' subdomain for testing purposes?

a simple .htaccess will do the job:

Quote

# rewrite to www
RewriteCond %{HTTP_HOST} !^www\.fjeldgruppen.\.dk$
RewriteRule ^(.*)$ http://www.fjeldgruppen.dk/ [L,R=301]


--
regards from germany
..::[Zikula Application Framework]::.. ..::[SEO-Blog]::.. ..::[CMS Sicherheit]::..
Lars: now I am not able to use fjeldgruppen.dk due to the redirect which always lands me on www.fjeldgruppen.dk. I assume this is what you wanted.

The result is that I never get a cookie for fjeldgruppen.dk (without 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.
sure, this is only for verifying the problem icon_wink
@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 www.fjeldgruppen.dk. I assume this is what you wanted.

The result is that I never get a cookie for fjeldgruppen.dk (without 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 www.fjeldgruppen.dk. I assume this is what you wanted.

The result is that I never get a cookie for fjeldgruppen.dk (without 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 www.fg.dk (sends PNSID=A) - (session ID "A" is recognized, so no need to return a new one)
3) Login www.fg.dk (sends PNSID=A) APPARENTLY FAILS - (returns PNSID=B)
4) Get www.fg.dk (sends PNSID=A + PNSID=B) - (returns PNSID=C)
5) Get 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 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
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.org/rfc/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 www.fg.dk it should also be .fg.dk.

This would mean sessions for fg.dk and 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...
icon_confused

--
- 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 icon_eek ) it will. ;)

JørnWildt

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

icon_wink 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

nestormateo

@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?


Yes, the lifetime of sessions from a certain IP range (WAN) is 25 years, outside that range it's 0. But if need be I'll hack that a bit when we upgrade to .8.