Core-Devs need your help: Login Problems :: Zikula Community

Try Zikula 1.3.1!New core, modules & more

Download Zikula!Version 1.2.8 (stable)

Core-Devs need your help: Login Problems

Print topic

Go to page [-1] 1 - 2 - 3 [+1]:

larsneo

Rank: Software Foundation

Registered: Dec 31, 1969

Last visit: Oct 21, 2009

Posts: 3814
Posted: Mar 26, 2008 - 11:50 PM

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]::..
eckerl

Rank: Softmore

Registered: Apr 26, 2002

Last visit: Oct 21, 2009

Posts: 164
Posted: Mar 27, 2008 - 03:17 AM

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.
thesubmitter

Rank: Freshman

Registered: Jan 31, 2005

Last visit: Oct 21, 2009

Posts: 51
Posted: Apr 01, 2008 - 04:48 PM

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
AmmoDump

Rank: Team Member

Registered: Dec 07, 2003

Last visit: May 09, 2010

Posts: 2703
Posted: Apr 01, 2008 - 06:34 PM

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
J�rnWildt

Rank: Softmore

Registered: Jul 02, 2002

Last visit: Oct 21, 2009

Posts: 240
Posted: Apr 01, 2008 - 08:18 PM

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).
J�rnWildt

Rank: Softmore

Registered: Jul 02, 2002

Last visit: Oct 21, 2009

Posts: 240
Posted: Apr 01, 2008 - 09:34 PM

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
J�rnWildt

Rank: Softmore

Registered: Jul 02, 2002

Last visit: Oct 21, 2009

Posts: 240
Posted: Apr 01, 2008 - 09:48 PM

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
dits

Rank: Developer

Registered: Feb 17, 2005

Last visit: May 21, 2010

Posts: 684
Posted: Apr 01, 2008 - 10:04 PM

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
nestormateo

Rank: Team Member

Registered: Sep 06, 2006

Last visit: May 09, 2010

Posts: 2411
Posted: Apr 02, 2008 - 06:58 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
dits

Rank: Developer

Registered: Feb 17, 2005

Last visit: May 21, 2010

Posts: 684
Posted: Apr 02, 2008 - 07:36 AM

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

Rank: Team Member

Registered: Sep 06, 2006

Last visit: May 09, 2010

Posts: 2411
Posted: Apr 02, 2008 - 08:03 AM

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
J�rnWildt

Rank: Softmore

Registered: Jul 02, 2002

Last visit: Oct 21, 2009

Posts: 240
Posted: Apr 02, 2008 - 09:24 AM

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

Rank: Team Member

Registered: Dec 07, 2003

Last visit: May 09, 2010

Posts: 2703
Posted: Apr 02, 2008 - 09:37 AM

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

--
David Pahl
Zikula Support Team
dits

Rank: Developer

Registered: Feb 17, 2005

Last visit: May 21, 2010

Posts: 684
Posted: Apr 02, 2008 - 10:38 AM

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. ;)
nestormateo

Rank: Team Member

Registered: Sep 06, 2006

Last visit: May 09, 2010

Posts: 2411
Posted: Apr 02, 2008 - 01:21 PM

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