Auth / login / cookie problems, proposed fix

valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2005-04-21 21:21

Task: Fix Auth / login problems caused by conflicting cookies.
Referring to bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1166376&group_id=7130&atid=107130
and numerous forum posts.

Numerous users have complained that they can't login. This problem usually arises, when G2 is accessed with different urls.
- when accessed as standalone and as embedded
- when accessed as www.domain.com/... and as domain.com

Example: embedded/standalone G2
- cookie from embedded: path = /
- cookie from standalone: path = /gallery2/
1. user logs out in embedded -> cookie with path = / is for an anonymous G2 session
2. user visits G2. browser sends cookie for path = / and for path = /gallery2/. Somehow, cookie with path = / has precedence.
3. G2 sends html, user is not logged in.
4. User tries to login, G2 sends cookie to browser: cookie with path = /gallery2/ is now for a logged in session.
5. User requests next G2 view, browser sends again both cookies, somehow the one with path = / has precedence.
7. G2 checks the session from the path = / cookie and resumes the anonymous session.

-> G2 will always set the path = /gallery2/ cookie but read the path = / cookie -> can't login unless cookie with path = / is deleted on client browser.

Example 2: www.domain.com/g2/, domain.com/g2/
Same issue, but now with domains instead of paths. G2 sets the www.domain.com cookie, and receives the .domain.com cookie.

It's not possible that G2 always updates the cookie it received, because the browser doesn't send the the cookie path/domain in its cookie-header which it sends to the server.

RFC 2109 and 2965 describe the cookie management. 2965 is newer and makes 2109 obsolete.

From the RFCs:
About which cookies the user agent (or browser) should send back to the server:

Quote:
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.

So, G2 should receive multiple GALLERYSID cookies when multiple are present on the browser matching the path or a substring of the path.

An example from the RFC:

Quote:
4.2 Example 2

This example illustrates the effect of the Path attribute. All
detail of request and response headers has been omitted. Assume the
user agent has no stored cookies.

Imagine the user agent has received, in response to earlier requests,
the response headers

Set-Cookie2: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"

and

Set-Cookie2: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"

A subsequent request by the user agent to the (same) server for URLs
of the form /acme/ammo/... would include the following request
header:

Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"

Note that the NAME=VALUE pair for the cookie with the more specific
Path attribute, /acme/ammo, comes before the one with the less
specific Path attribute, /acme. Further note that the same cookie
name appears more than once.

I tested this. There are a number of options to retrieve cookie data in php. $_COOKIE is indexed by NAME, so you get only a single GALLERYSID cookie. $_GLOBALS['HTTP_SERVER_VARS'] lists all GALLERYSID cookies! But no paths for the cookies :(
Same for $_GLOBALS['_SERVER'] = $_SERVER.
So, why don't we get the path for each component? The RFC defines that the browser sends the path to the server. If we received the path, we could choose the more specific path / update the right cookie.
I checked the packets sent from FF and IE, both don't send the path, they just send a single Attribut Cookie: NAME=VALUE; NAME=VALUE; ... list.

G2 (GallerySession.class::init) doesn't check $_SERVER['HTTP_COOKIE'], so it only receives/checks one GALLERYSID cookie per request.

Proposed fix A:
Set Path = '/' and domain = '.domain.com' independent of the full path and the subdomain. I saw this in phpbb, it should work.
That way G2 will never have different cookies for the same install, even if accessed in different ways.

Problem of the proposed fix:
What if multiple G2 are running on the same domain? Probably in different paths or subdomains. No problem as long no user visits no more than a single of these G2 installs.
But here's the real solution:
cookie (domain, path and) name should be configurable. If they are not set /overriden by the admin, the defaults will be used (.domain.com, /, GALLERYSID) and this will be the best solution for 90% of all users. Those who need multiple G2 on a single server, can define another cookie name for all different G2 installations.
These values if set, should be defined in config.php to not require a DB lookup for this query as the session is used too often and too early.

The cookie name could also be GALLERYSID . rand(0,1000) set on install time. That way, the probability that two G2 on the same domain would have to solve a cookie conflict by changing the cookie name manually would be reduced.

Proposed fix B:
Instead of checking $_COOKIE, we could check $_SERVER['HTTP_COOKIE']. The RFC defines that the more specific cookies should be listed first. $_COOKIE lists only the one GALLERYSID cookie that is listed as the last of all cookies with the name = GALLERYSID in this list.
G2 should choose the first cookie with name = GALLERYSID in the list $_SERVER['HTTP_COOKIE'], because it's path is more specific, i.e. it will always be the one G2 tries to overwrite / G2 sends back.

This would fix the standalone/embedded G2 auth/login problems.
But this probably doesn't solve the subdomain.domain.com/domain.com auth/login problem. From the RFC:

Quote:
Ordering with respect to other
attributes (e.g., Domain) is unspecified.

It would be interesting what the practice is.

Conclusion:
I'd prefer Fix B, because it's easier / less admin options. But if it doesn't solve the sub.domain.com problem, then we have to go with Fix A.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2005-04-22 18:54

PS: I tried to confirm / reproduce the sub.domain.com vs. domain.com login problems. I couldn't (tested with FF and IE).

I.e. i only know / can reproduce the embedded vs. standalone login problems. Could anyone describe a step by step guide to reproduce a non-embedded login problem?
If you login in sub.domain.com and then change to a site: domain.com, you have to login again of course. With url rewrite, this is already fixed. But that's about the only issue. Because login works for me in all cases.
Theoretically, you should be able to reproduce the issue by first creating to anonymous sessions / cookies, one with accessing G2 with domain.com, the other by accessing G2 with www.domain.com.
Then try to login in G2 by accessing it with www.domain.com. If there was a problem, it should arise here. But it doesn't.
When accessing G2 by domain.com, the www.domain.com cookie won't match, because its domain .www.domain.com doesn't match domain.com or a substring of domain.com.

edit:
i've searched the forums for login problems since march 1st.
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=28459&highlight=login
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=28069&highlight=login
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=27288&highlight=login
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=27028&highlight=login (2, 3 people complaining)
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=27017&highlight=login (definitely using embedded/standalone)
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=26590&highlight=login
* http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=26625&highlight=login

it could also be session timeout related.

at least 1 of these guys isn't using embedded G2. so yes, there seems to be a problem. but do we know the cause? can we reprodoce it? no.
but the cause for the embedded G2 is known and could be fixed easily with Fix B.

and probably, some of these issues were caused by a bug that was fixed in http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&t=26590&highlight=login, i.e. they still used an old version.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2005-04-23 00:17

mindless and I discussed the topic in irc. We both think that the following cookie management should fix all issues:

domain = don't set
path = dynamic (getcookiepath())
and get cookie from the php var, that lists all cookies ($_SERVER['HTTP_COOKIE']), not $_COOKIE

Notes:
- The reason why www.domain.com vs. domain.com can be a problem is that there is no ordering rule for the domain part of cookies. so different browsers/OS/... can list the more specific domains first or last, whatever they want. So this can be a problem for certain users although we can't reproduce it.

- the reason why domain = don't set is the solution for this problem is:

RFC 2965 for the user agent behavior wrote:
Domain Defaults to the effective request-host. (Note that because
there is no dot at the beginning of effective request-host,
the default Domain can only domain-match itself.)

- The embedded vs. standalone is fixed by choosing the right cookie, i.e. not using $_COOKIE.

- We have to check common browsers: IE, FF, opera, ... if they behave like we think they (should) behave.

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Sat, 2005-04-23 01:10

Thanks for doing the research, valiant!
I tested Moz,FF,IE,Opera on win2k and FF,Safari on OSX.. all behaved as expected: with a / and /path cookie and accessing a url in /path it always listed the /path cookie first in $_SERVER['HTTP_COOKIE']. In all cases I tested setting the / cookie first and setting the /path cookie first (clearing cookies between tests, of course).

So, please proceed with the fix!

btw, see http://bugs.php.net/ for info about filing php bugs (we think it may be a bug that $_COOKIE contains the last listed, ie least specific, cookie when multiple values are sent..)

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sat, 2005-04-23 07:19

i tried filing this exact $_COOKIE bug yesterday. the php.net captcha test wasn't working correctly, now i'm waiting for a fix for that first. but they are already looking into it (the captcha thing).

I'll also test the www. vs. domain thing on multiple browsers.

Current G2 version:
- Internet Explorer/Windows XP: in my test, it listed first the less specific domain.com, then www.domain.com cookie when requesting a page for www.domain.com/g2
when requesting domain.com/g2, only the domain.com cookie was returned
- Firefox/Windows XP: same behavior as IE, request www.domain.com/g2 and it lists the domain.com cookie before the www.domain.com
- Firefox/Linux x86 Gentoo: exactly the other way around. First the more specific www.domain.com cookie, then the less specific.domain.com cookie.
- Firefox/Linux x86 unknown distribution: Like IE on windows, first the less specific domain cookie, then the other.

Conclusion:
So this is quite interesting. The RFC says, "it doesn't matter in what order you order by the domain field" and the browsers do it exactly like that. The same browser software has a different order for the domain matching on different platforms.

Now I'll test how it works when we apply our fix.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2005-04-24 00:42

mindless, I have a fix now.

As discussed:
In GallerySession:
- don't set domain

New method in GalleryUtilities:

    /**
     * Fix the superglobal $_COOKIE to conform with RFC 2965
     *
     * We don't use $_COOKIE[$cookiename], because it doesn't conform to RFC 2965 (the
     * cookie standard), i.e. in $_COOKIE, we don't get the cookie with the most specific path for
     * a given cookie name, we get the cookie with the least specific cookie path.
     * This function does it exactly the other way around, to a) fix our cookie/login problems and
     * to b) conform with the RFC.
     *
     * This function reevaluates the HTTP Cookie header and populates $_COOKIE with the correct
     * cookies.
     *
     * @param boolean force the reevaluation of the HTTP header string Cookie
     * @static
     */
    function fixCookieVars($force = false) {
	static $fixed;
	if (!isset($fixed) || $force) {
	    $fixed = true;
	    if (isset($_SERVER['HTTP_COOKIE']) && !empty($_SERVER['HTTP_COOKIE'])) {
		$allCookies = explode(';', $_SERVER['HTTP_COOKIE']);
		/*
		 * Get rid of less specific cookies if multiple cookies with the same NAME
		 * are present. Do this by going from left/first cookie to right/last cookie.
		 */
		$_COOKIE = array();
		foreach ($allCookies as $cookie) {
		    /* Split NAME [=VALUE], value is optional */
		    $cookie = explode('=', $cookie);
		    $key = preg_replace('|\s|', '', $cookie[0]);
		    $value = isset($cookie[1]) ? $cookie[1] : '';
		    if (!isset($_COOKIE[$key])) {
			$_COOKIE[$key] = $value;
		    }
		}
	    }
	}
    }

This method could be called in bootstrap.inc or in GallerySession::init().

It fixes the embedded/standalone issue and the www. vs. domain.com issue.
Tested with Win XP FF/IE, FF linux x86 Gentoo.

But it has also a disadvantage:
1. login in G2 without url rewrite module in a www.domain.com page as admin
2. activate url rewrite module with base address domain.com
3. logout
4. browse to www.domain.com -> still logged in as admin
5. click on logout. logout link has domain.com style and not www.domain.com -> you can't loggout the www.domain.com cookie/session unless you manually copy the logout link and add a www. at the beginning.

-> should the url rewrite module delete the old cookie when it's activating and create a new one?

But the good news is that you can browse to www.domain.com and login and remain logged in even if url rewrite is installed (the redirect automatically redirects to a baseaddress address and then the cookie is set).

Questions:
1. Where should we move the fixCookieVars() code? IMO, we don't need it in bootstrap.inc, this would slow down the public downLoadItem requests.
It's needed
- before / at the start of GallerySession::init
- in GalleryEmbed::logout because it first gets the cookie data, then the Gallery session.

2. What about the described problem case? Is a change to the url rewrite module necessary (reset cookies).

3. Unit tests: It's a minor change.
- But we could create a unit test that manually populates $_COOKIE with the wrong data and HTTP header Cookie: with the some cookie data and then check the init session call to check if the right sessionId was picked
- can't test the www. vs. domain thing because it's up to the browser what he decides. but we could make sure that G2 doesn't set the cookie domain in a test.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2005-04-24 02:04

Sidenote:
Using the default domain, i.e. not setting the domain in the cookies...
FF and Opera conform to the RFC in the sense that only "the default Domain can only domain-match itself", so they send only the www.domain.com cookie to the server, not the domain.com.
IE doesn't comply with the RFC and sends both cookies, www.domain.com and domain.com for a request on a page on www.domain.com.
The good news:
On my windows xp box, it works nevertheless, because IE sends always the www.domain.com as the first and domain.com as the second (precedence).
Now the question is:
- Is this only luck? I tested it with having domain.com the newer and as the older cookie, both times it was the second cookie. good.

I will file this as a bug on ms.com

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Sun, 2005-04-24 02:08

1. is GalleryInitFirstPass a good place to call fixCookieVars?

2. the problem case you describe is a problem of rewrite module.. ideally it should use the hostname in the request and never jump from www. to domain.com. we should proceed with this fix and inform pelle of this issue.

3. yup, those sound like good tests.

do you need a preg_replace call, or is trim($key) sufficient? (maybe trim runs a little faster?)

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Sun, 2005-04-24 02:17

@IE - confirmed.. I also tried setting cookies in either order and both times got the cookie for exact-match (www.domain.com) listed first.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2005-04-24 02:34

mindless, thanks for the answers!

@trim: right, should be faster, i.e. not loading the regexp engine.

@1. / GalleryInitFirstPass: yes. GallerySession::init right after global $gallery; would be even better IMO. if you do something with sessions, you have to use gallerysession.class anyway, but not necessarily GalleryInitFirstPass.
And GalleryEmbed::logout needs to call it too.

@IE: thanks. well, if we wanted to go for sure, we had to set the domain explicitely to alway the same value, i.e. .domain.com by default. but as described in this thread, this would have disadvantages. I'd say we stick to the "don't set domain" pattern until we get a user that complains about IE login problems.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2005-04-24 02:50

@url rewrite:
having url rewrite jump from sub.domain.com to domain.com should be ok. i.e. it's a feature. normalizing all requests from domain.com and sub.domain.com to domain.com. In this case, the domain should/could be set to .domain.com or .sub.domain.com (or whatever is the baseaddress in url rewrite for all urls).

but disabling this jumps from www.domain.com to domain.com would solve it too. but it would require some changes in the url rewrite module, because it starts all urls with the baseaddress which is protocol://some.domain.com/path/.

 
ozgreg
ozgreg's picture

Joined: 2003-10-18
Posts: 1378
Posted: Sun, 2005-04-24 05:04

Don't want to throw this thread offtrack but I can confirm that the cookies problem in a slightly different way..

For Example (This is a real life example)

mysite.com has WP + G2 installed
testing.mysite.com has WP+G2 installed

G2 has a problem trying to log into testing.mysite.com (You have to use a different browser to get around the issue). Authentication is successful but it seems to be unable to set the cookie thus the login fails.. and you show up as guest again...

I found if the G2 cookie exists for mysite.com then G2 has problems logging into testing.mysite.com

Forcing the www in the mysite.com correctly fixes the issue and then allows the subdomains to login as the mysite.com cookie is not set..

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Sun, 2005-04-24 06:10

I think that falls under the cases we are fixing..

 
ozgreg
ozgreg's picture

Joined: 2003-10-18
Posts: 1378
Posted: Sun, 2005-04-24 06:18

Yeah I believe so also but it was worth just checking and reconfirming. I be able to simulate this issue again should you want to check your solutions..

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Sun, 2005-04-24 19:51

The php bug ($_COOKIE) has been fixed today.
See: http://bugs.php.net/bug.php?id=32802

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2005-04-25 00:36

wow, that was a fast fix for your bug report! (but a pretty slow fix since the bug was first filed in 2002! but closed as "bogus")

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 00:43

I'd like to wait for pelle's answer to the rewrite questions. I pmed him.

And I have to rewrite fixCookieVars.
○ NAME=value. value can be quoted-string with any 8-bit char in it. So explode(';', $_SERVER...) won't work.
○ ';' and ',' can be a delimiter
○ when parsing ignore attr=value pairs where attr starts with a dollar sign '$'
i.e. i have to write a little parser, explode can't be used.

But the rest is done. unit tests too.

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2005-04-25 00:45

valiant, if you haven't done so already, might be worth looking at php's source code to see how they parse it..

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 01:54

good idea. i hope they didn't use my fixCookieVars function just in C, lol.
i have found the fix in main/php_variables.c function php_register_variable_ex.
it's not easy to read to say the least.

called in sapi/isapi/php4isapi.c: php_register_variable("HTTP_COOKIE", SG(request_info).cookie_data, track_vars_array TSRMLS_CC);

SAPI_API SAPI_TREAT_DATA_FUNC(php_default_treat_data)
sets the separators ",", ";" and calls the parser/tokenizer. php_strtok_r(res, separator, &strtok_buf);

So, SAPI_TREAT_DATA_FUNC does the actual parsing for attr=value paris in the HTTP Cookie header string.
But as far as i understand the code, it doesn't check for separators in quoted-strings!

But the RFC 2695 is clear (together with http://rfc.net/rfc2616.html). the Cookie header can have quoted-strings, not only tokens.

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2005-04-25 03:50

time to build a simple test case and file another bug? :-)

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 05:32

mindless, maybe... but not now.

Have you time for a code review?
You should have received a mail with the diff.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 15:50

ok, i was wrong.
the http cookie header is urlencoded, so it's really easy.
i just have to do some checks on the name/values.

here's the new version of the diff:

http://dev.nei.ch/cookie_fix.diff.gz

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 20:22

There's more to populating the $_COOKIE var then it seems.
The cookie vars can be array, nested arrays and there are some strange rules.

We don't use array cookies, so my code works as it is for G2. But when embedded, my code would screw up the $_COOKIE var and if the other application uses array cookies, that's not too good.

So here are the two alternatives:

1. Make the fixCookieVars correct, more complex, a little hard to read, but it would correctly decode array cookies from HTTP cookie header to $_COOKIE.
+ Correct cookies
- more complex, less readable / maintainable code
- a little slower

2. Make fixCookieVars only reset / evaluate well known G2 variables and let all other cookies in $_COOKIE. Or even better and also easy: fix only non-array cookie vars.
+ easy fix
- ATM, there are 3 cookies: SESSION_ID_PARAMETER (G2), g2Setup (/lib/tools/), and the phpsessionsid (installer, upgrader). Perhaps, we will want to use array cookies in future, who knows.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 20:25

this is the php source code which i should mimic now in G2...
I'm ok with alternative #1, not sure about alternative #2.

PHPAPI void php_register_variable_ex(char *var, zval *val, pval *track_vars_array TSRMLS_DC)
{
	char *p = NULL;
	char *ip;		/* index pointer */
	char *index;
	int var_len, index_len;
	zval *gpc_element, **gpc_element_p, *tmp;
	zend_bool is_array;
	HashTable *symtable1=NULL;

	assert(var != NULL);
	
	if (track_vars_array) {
		symtable1 = Z_ARRVAL_P(track_vars_array);
	} else if (PG(register_globals)) {
		symtable1 = EG(active_symbol_table);
	}
	if (!symtable1) {
		/* Nothing to do */
		zval_dtor(val);
		return;
	}

	/*
	 * Prepare variable name
	 */
	ip = strchr(var, '[');
	if (ip) {
		is_array = 1;
		*ip = 0;
	} else {
		is_array = 0;
	}
	/* ignore leading spaces in the variable name */
	while (*var && *var==' ') {
		var++;
	}
	var_len = strlen(var);
	if (var_len==0) { /* empty variable name, or variable name with a space in it */
		zval_dtor(val);
		return;
	}
	/* ensure that we don't have spaces or dots in the variable name (not binary safe) */
	for (p=var; *p; p++) {
		switch(*p) {
			case ' ':
			case '.':
				*p='_';
				break;
		}
	}

	index = var;
	index_len = var_len;

	while (1) {
		if (is_array) {
			char *escaped_index = NULL, *index_s;
			int new_idx_len = 0;

			ip++;
			index_s = ip;
			if (isspace(*ip)) {
				ip++;
			}
			if (*ip==']') {
				index_s = NULL;
			} else {
				ip = strchr(ip, ']');
				if (!ip) {
					/* PHP variables cannot contain '[' in their names, so we replace the character with a '_' */
					*(index_s - 1) = '_';
					
					index_len = var_len = 0;
					if (index) {
						index_len = var_len = strlen(index);
					}
					goto plain_var;
					return;
				}
				*ip = 0;
				new_idx_len = strlen(index_s);	
			}

			if (!index) {
				MAKE_STD_ZVAL(gpc_element);
				array_init(gpc_element);
				zend_hash_next_index_insert(symtable1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
			} else {
				if (PG(magic_quotes_gpc) && (index!=var)) {
					/* no need to addslashes() the index if it's the main variable name */
					escaped_index = php_addslashes(index, index_len, &index_len, 0 TSRMLS_CC);
				} else {
					escaped_index = index;
				}
				if (zend_hash_find(symtable1, escaped_index, index_len+1, (void **) &gpc_element_p)==FAILURE
					|| Z_TYPE_PP(gpc_element_p) != IS_ARRAY) {
					MAKE_STD_ZVAL(gpc_element);
					array_init(gpc_element);
					zend_hash_update(symtable1, escaped_index, index_len+1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
				}
				if (index!=escaped_index) {
					efree(escaped_index);
				}
			}
			symtable1 = Z_ARRVAL_PP(gpc_element_p);
			/* ip pointed to the '[' character, now obtain the key */
			index = index_s;
			index_len = new_idx_len;

			ip++;
			if (*ip=='[') {
				is_array = 1;
				*ip = 0;
			} else {
				is_array = 0;
			}
		} else {
plain_var:
			MAKE_STD_ZVAL(gpc_element);
			gpc_element->value = val->value;
			Z_TYPE_P(gpc_element) = Z_TYPE_P(val);
			if (!index) {
				zend_hash_next_index_insert(symtable1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
			} else {
				if (PG(magic_quotes_gpc) && (index!=var)) {
					char *escaped_index = php_addslashes(index, index_len, &index_len, 0 TSRMLS_CC);
 					/* 
 					 * According to rfc2965, more specific paths are listed above the less specific ones.
 					 * If we encounter a duplicate cookie name, we should skip it, since it is not possible
 					 * to have the same (plain text) cookie name for the same path and we should not overwrite
 					 * more specific cookies with the less specific ones.
 				 	 */
 					if (PG(http_globals)[TRACK_VARS_COOKIE] && symtable1 == Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_COOKIE]) && 
 							zend_hash_find(symtable1, escaped_index, index_len+1, (void **) &tmp) != FAILURE) {
						efree(escaped_index);
 						break;
					}
					zend_hash_update(symtable1, escaped_index, index_len+1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
					efree(escaped_index);
				} else if (!PG(http_globals)[TRACK_VARS_COOKIE] || symtable1 != Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_COOKIE]) || zend_hash_find(symtable1, index, index_len+1, (void **) tmp) == FAILURE) {
					zend_hash_update(symtable1, index, index_len+1, &gpc_element, sizeof(zval *), (void **) &gpc_element_p);
				}
			}
			break;
		}
	}
}
 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2005-04-25 22:27

i'm perfectly happy with making fixCookieVars take a list of cookie names to fix, and comment the function to say it only works for "simple" cookie values.. this will save you from porting that whole thing above, right?
can't we get away with fixing only the session id cookie? seem ok to me to require installer/upgrader and unit tests to be accessed in standalone only.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Mon, 2005-04-25 23:27

mindless, but what if some module devs start creating their own cookies. Or do we strongly discourage that?

I agree that the installer/upgrader and /lib/tools will only be accessed in standalone.
So, if module devs should not use their own cookies, fixing only GALLERYSID would be ok.
Fixing only GALLERYSID is a little easier than fixing all non-array cookies, but not a lot. It's about the same logic. We're talking about 40-50 lines of code difference. Fixing all arrays would take another 50-100 lines :)

Accepting a list of cookies to fix rather than fixing all non-array cookies could be more complicated than just fixing all of them.

So I went with fixing all non-array, non '[' or ']' containing cookies.

PS: After reading the cookie and http/1.1 rfc, I still think that the http cookie header could actually contain quoted-strings etc. But I won't handle it more complicated than php itself, we wouldn't gain anything.

The hopefully feature-final fix diff:
http://dev.nei.ch/cookie_fix.diff.gz

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Mon, 2005-04-25 23:31

ok, sounds good to me.. will review asap.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 07:14

mindless has pointed out that $_SERVER['HTTP_COOKIE'] could be problematic on IIS. my guess is that it's available for modern ISAPI (quite sure), but not for old ISAPI and not for IIS/php/cgi.

That's a fundamental flaw in our fix. Maybe we need another solution.

 
damato
damato's picture

Joined: 2004-10-30
Posts: 29
Posted: Tue, 2005-04-26 07:51

Just a quick sidnote/question:

On my gallery I can also confirm that I have a problem logging in since about 1-2 weeks (I do daily CVS updates), so chances are high that I am also suffering from that particular cookie problem. see http://gallery.light-speed.de/

The question is now that I see valiant was mentioned it is fixed in PHP:

1) Is the proposed fix to update the PHP5 version to a later one, because I can't wait until a new PHP5 version is out since that would render my gallery useless until then

2) Another question is why is my gallery using URLs with always two slashes "//" like the following one: http://gallery.light-speed.de//v/damato/
I recognized that this changed also in one of the latest CVS updates, so could probably this be another problem why I can't login to my gallery anymore?

thanks for your help.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Tue, 2005-04-26 07:54

I'm showing up late to this party. It looks like you've done a ton of due diligence. Clearly we want to do this the right way and have cookies associated with a given path, but as always we're balked by bugs in the various servers and browsers that we choose to support.

I think that we should aim for simplicity. And simplicity is...

valiant wrote:
Proposed fix A:
Set Path = '/' and domain = '.domain.com' independent of the full path and the subdomain. I saw this in phpbb, it should work.
That way G2 will never have different cookies for the same install, even if accessed in different ways.

Problem of the proposed fix:
What if multiple G2 are running on the same domain? Probably in different paths or subdomains. No problem as long no user visits no more than a single of these G2 installs.
But here's the real solution:
cookie (domain, path and) name should be configurable. If they are not set /overriden by the admin, the defaults will be used (.domain.com, /, GALLERYSID) and this will be the best solution for 90% of all users. Those who need multiple G2 on a single server, can define another cookie name for all different G2 installations.
These values if set, should be defined in config.php to not require a DB lookup for this query as the session is used too often and too early.

The cookie name could also be GALLERYSID . rand(0,1000) set on install time. That way, the probability that two G2 on the same domain would have to solve a cookie conflict by changing the cookie name manually would be reduced.

If we start with the simple solution where we use GALLERYSID everywhere with a path of / then this takes care of at least 80% of our users since they'll only have one gallery (and maybe one CMS). This gets us most of the way there, and in fact if you just use one GALLERYSID across multiple galleries it'll work because the same session id will get stored into the two different g2data/sessions dirs. As soon as you log into a G2 it'll change the session id, though so you won't be able to log into both at the same time.

If we want to get THAT working, we could be tricky and say that our desired cookie id is "G2SID . substr(md5($path), 0, 4)" which even with just 4 bytes will give us collision odds of 1:36^4 which I can live with. We'll calculate our expected session id variable that way and always know which sid to look for. Performance hit should be minimal.

Is this the One True Way that we want to develop G2? No. :-( But I think in this case we'll have to be pragmatic and live with it...

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 09:08

bharat, thanks for putting me back on track.

Our Fix with no domain and dynamic path seemed like the easiest and best solution. But then we have found a php bug and an IE bug. The IE bug was not a big deal because if php conformed with RFC 2965, it wouldn't be exposed.
Fixing the php bug seemed also quite easy, but obviously it can't be done for all webserver configurations (to be verified).

So we're back to fix A which seemed like the worse solution but it's more robust in practice.
And with your suggestion to choose GALLERYSID as "G2SID" . substr(md5($galleryId), 0,4) it's a really good solution!
(choose galleryId or g2dataPath, just something that is an invariant between embedded/standalone)
-> No multiple GALLERYSID cookies per G2 install, embedded or not = problem solved.

If everyone agrees, I'd go back, don't include fixCookieVars in G2 and use Fix A with a unique cookiename as described above.

 
bharat
bharat's picture

Joined: 2002-05-21
Posts: 7994
Posted: Tue, 2005-04-26 09:15

Sounds good to me. And put a comment in the code explaining why we're doing this and a note to revisit this decision in, say, a year when the situation may be different.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 10:51

Sure. I had a lot of comments and explanations in my current diff.

damato,
@php: php has (at least) two development branches. 4.3.x and 5.x. AFAIK, both branches were fixed, at least php4, because the above code snippet is from the php4 source which are already fixed.

@ // in your urls. this is because of a bug in the url rewrite module. i've informed pelle, the author of the module, and proposed a fix. i'm sure it will be fixed soon in the G2 cvs.

 
damato
damato's picture

Joined: 2004-10-30
Posts: 29
Posted: Tue, 2005-04-26 10:56
valiant wrote:

damato,
@php: php has (at least) two development branches. 4.3.x and 5.x. AFAIK, both branches were fixed, at least php4, because the above code snippet is from the php4 source which are already fixed.

Sorry, but I still don't get the point how I can fix my recent login problems I am facing since about 1-2 weeks now (I am not able to login at all)? Do I have to install a more recent php5 version or will your patch to the gallery2 sources fix my problems?

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 11:11

no, just disable the url rewrite module to get rid of the // and flush your browser cookie cache for this domain.

mindless, bharat, the new SESSION_ID_PARAMETER depends on $gallery->getConfig('galleryId') and we still want to define that constant at the top of GallerySession.class.
Can I assume that GallerySession.class is always included AFTER bootstrap.inc, i.e. can I assume that the global variable $gallery exists?
Then I'd just call
global $gallery;
define('SESSION_ID_PARAMETER', 'G2SID' . substr(md5($gallery->getConfig('galleryId')), 0, 4));

I just tested if md5 accepts NULL as parameter, and that works without problems.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 16:42

bharat, mindless, back to our fixCookieVars + no domain + dynamic path solution:

I have tested Windows XP SP 2 iis 5.1 + php/cgi 4.3.11 and + php-isapi 4.3.11 and in both cases, i get what we need. $_SERVER['HTTP_COOKIE'] is set.

I don't know why http://koivi.com/apache-iis-php-server-array.php says something different (but google indicates that this is a problem).

It could very well be that for certain IIS configs (old iis, old isapi?, config, ...) we don't get the $_SERVER['HTTP_COOKIE'].

How should we procede?
Our fix is finished and seems to work on apache/iis module/isapi/cgi. But there are strong hints that it won't work on some, maybe old iis setups. What we could do: add isset($_SERVER['HTTP_COOKIE']) to the systemcheck step. (But we only get a value there, if the client browser accepts cookies).

We could also go with fix A, which is quite simple and is very robust. On the negative side, we have a cookie name which doesn't win any beauty contest.

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2005-04-26 16:48

i guess i prefer the solution valiant has put together.. why solve the 80% case when we can solve the 99% case?

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Tue, 2005-04-26 18:08

mindless and I were discussing the issue in #gallery...
about Fix A:
- sets the domain to .domain.com unless it's a numerical (IPv4/6) host. in this case, the domain is not set (no subdomains -> no multiple cookies).
- The cookiename should be NAME . substr(md5($galleryId),0,4); because g2dataPath could be equal for multiple installs.

we compiled a pro's con's list:
- pro: no HTTP_COOKIE dependence
- pro: robust
- con: hard to identify which cookie is for which site on same domain
- con: small probability of cookie conflict between sites on same domain
- con: other cookies must also adopt this naming scheme or have conflict between sites in same domain, i.e. the cookies should go through a function which adds the substr(md5(galleryId), 0, 4)
- pro: you can take out all the cookie-path stuff to figure out the right path when embedded
- con: when people move their gallery from one folder to another, due to whatever reason, then we get "can't login" posts. but a FAQ entry would do it.

- we could define('SESSION_ID_PARAMETER', 'G2SID' . substr(md5(galleryId), 0, 4)); in config.php then you could identify cookies more easily

- we have getCookieVar($key) which could be modified to check for $key . getconfig(...), we could also create setCookieVar($key, $value, $extraHeader); and then we could make sure in codeaudittest, that the $_COOKIE, and setCookie, and header('Set-Cookie" are not called anywhere else
- or we just inform our module devs that they should add the id to the cookiename and have the id in the config, no special setcookie function needed in this case

pro's and con's of fixCookieVars:
- pro: fixes all non-array cookies, doesn't need further changes
- con: dependency on $_SERVER[HTTP_COOKIE], reason unknown that some have it not set on MS IIS webserver (see google for problems)
- pro: already implemented and unit tests are there
- con: parsing (time, load), although very lightweight

So, bharat, mindless, got any preferences?

Both approaches are ok. I'd like to finish this task and move on.
I'm tempted to choose the fixCookieVars solution until we get some feedback of new auth/login problems.

 
mindless
mindless's picture

Joined: 2004-01-04
Posts: 8601
Posted: Tue, 2005-04-26 21:22

after our discussion I understand the HTTP_COOKIE dependence better and see that the md5 thing in the cookie name is supposed to get from solving the 80% case to solving all.. so i've moved close to on-the-fence, but still slightly favor fixCookieVars because then we use cookies correctly, hybrid/slider cookies will work, and the code has been written. (hybrid/slider won't be able to call setCookieVar because their cookies are set by javascript in the browser after the page has loaded.. i guess we could have a client-side version of setCookieVar..)

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2005-04-27 00:22

Ok, another IRC discussion yielded following consent:
- Go with fixCookieVars
- Fall back to Fix A with unique cookie names if further problems are reported due to missing $_SERVER['HTTP_COOKIE'].

Sidenote: bharat and mindless explained me the ad-hoc cookies for hybrid/slider layouts. Javascript -> user-agent -> Javascript cookies. So these cookies shouldn't be of any concern to server side cookie behavior.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2005-04-27 01:49

Committed the fix to cvs. Get the next nightly snapshot in about 9 hours.

 
pelle
pelle's picture

Joined: 2004-12-10
Posts: 389
Posted: Thu, 2005-04-28 13:16

A small clearification on how the rewrite module creates URLs. They are built the same way as with the bulk url generator - it uses makeUrl to create the base adress.

valiant wrote:
activate url rewrite module with base address domain.com

This is not possible any more. When you activate the module it saves the path, not the entire URL base (it used to save 'http://www.example.com/gallery2/', now with 0.9.3 it only saves '/gallery2/').

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2005-04-28 13:33
Quote:
When you activate the module it saves the path, not the entire URL base

that's perfect.

 
buut
buut's picture

Joined: 2003-06-18
Posts: 196
Posted: Thu, 2005-04-28 22:54

The cookies thing was very annoying to me!. With core 0.9.14 (28 april) it looks like it is solved. At least it works for me! (IIS v5.0/php cgi/IEv6)
Great Job!

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2005-04-28 23:01

buut, good to hear!
And especially that it works on your cgi/iis install!!
thanks :)

i'd like to test something. can you run yourgalleryurl/lib/tools/phpunit/index.php?filter=utilities
?
everything green?

 
buut
buut's picture

Joined: 2003-06-18
Posts: 196
Posted: Thu, 2005-04-28 23:56

Valiant
For your Pleasure...

Test Results
# Module Class Function Success? Time 
1 search  searchutilitiestest  testsanitizesearchcriteria  OK 0.7052 
2 core  utilitiestest  testgetfilenamecomponents  OK 0.6173 
3 core  utilitiestest  testgetfilenamecomponents2  OK 0.5904 
4 core  utilitiestest  testgetfilenamecomponents3  OK 0.6156 
5 core  utilitiestest  testgetfileextension  OK 0.6007 
6 core  utilitiestest  testgetfilebase  OK 0.5920 
7 core  utilitiestest  testmaliciousbrowserinput1  OK 0.6250 
8 core  utilitiestest  testarrayinput  OK 0.5968 
9 core  utilitiestest  testgetformvariables  OK 0.6467 
10 core  utilitiestest  testgetformvariables2  OK 0.6153 
11 core  utilitiestest  testgetformvariables3  OK 0.5951 
12 core  utilitiestest  testgetformvariables4  OK 0.6033 
13 core  utilitiestest  testgetformvariablesnoprefix  OK 0.6021 
14 core  utilitiestest  testgetformvariablesnoprefix2  OK 0.6109 
15 core  utilitiestest  testgetrequestvariables  OK 0.6040 
16 core  utilitiestest  testsanitizeinputvalue1  OK 0.5957 
17 core  utilitiestest  testsanitizeinputvalue2  OK 0.6373 
18 core  utilitiestest  testsanitizeroundtrip  OK 0.6101 
19 core  utilitiestest  testmakemarkers  OK 0.6392 
20 core  utilitiestest  testconvertpathtourl  OK 0.6203 
21 core  utilitiestest  testrequireonce  OK 0.5983 
22 core  utilitiestest  testshrinkdimensionstofit  OK 0.6408 
23 core  utilitiestest  testscaledimensionstofit  OK 0.6158 
24 core  utilitiestest  testisa  OK 0.5957 
25 core  utilitiestest  testisexactlya  OK 0.6428 
26 core  utilitiestest  testhasrequestvariable  OK 0.6094 
27 core  utilitiestest  testhasrequestvariable2  OK 0.6396 
28 core  utilitiestest  testremoverequestvariable  OK 0.6037 
29 core  utilitiestest  testremoverequestvariable2  OK 0.6110 
30 core  utilitiestest  testremoveformvariables  OK 0.6199 
31 core  utilitiestest  testgetremotehostaddress  OK 0.6003 
32 core  utilitiestest  testispathinlist  OK 0.6156 
33 core  utilitiestest  testprocessingpaths  OK 0.6378 
34 core  utilitiestest  testhtmlentitydecode  OK 0.6079 
35 core  utilitiestest  testentitysubstr  OK 0.6134 
36 core  utilitiestest  testcreatealbumtree  OK 0.6216 
37 core  utilitiestest  testgetfile  OK 0.5949 
38 core  utilitiestest  testgethttpdate  OK 0.6139 
39 core  utilitiestest  testiscompatiblewithapi  OK 0.5922 
40 core  utilitiestest  testgetphpinibool  OK 0.6098 
41 core  utilitiestest  testidentifysearchenginecrawlerfromrequest  OK 0.6285 
42 core  utilitiestest  testunicodevaluetoutf8value  OK 0.5897 
43 core  utilitiestest  testunicodeentitiestoutf8  OK 0.6124 
44 core  utilitiestest  testutf8tounicodeentities  OK 0.5916 
45 core  utilitiestest  testutf8substring  OK 0.6339 
46 core  utilitiestest  testgetservervar  OK 0.6118 
47 core  utilitiestest  testgetcookievar  OK 0.5980 
48 core  utilitiestest  testfixcookievars  OK 0.6209 

Summary
29.4942 seconds elapsed

48 tests run

0 failures.
 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Fri, 2005-04-29 00:02

great, thank :)

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Wed, 2005-05-04 21:14

Ok, new issue. We didn't cover all permutations of browsing in {standalone/embedded}, standalone cookie{not set/set for uid x}, embedded cookie{not set / set for uid y}
where x can, but doesn't have to be y.

We forgot about the case:
- standalone cookie = logged out and
- embedded cookie = logged in
Result:
All embedded G2 pages display correctly, but no images show up.
Reason:
The DownloadItem links (all <img src="url"> urls) in embedded are exactly the same as the DownloadItem links in standalone (for performance reasons).
G2 receives the DownloadItem requests along with at least the standalone cookie, perhaps also with the embedded G2 cookie. But the cookie standard defines that the standalone G2 cookie has precedence. So G2 says "this request was from a user which is logged out from G2. If the Item doesn't have sufficient permissions for guests, i'll raise a permission error".

Bottom line: We have to fix this issue.
We've discussed this issue on irc and here are the results...

Fix "fixCookieVars v.2":
Currently we use the "fixCookieVars v.1" fix for cookie / auth problems.
To extend this fix to cover the new problem, we could do the following:
- When generating urls in embedded G2: we'd have to tag all DownloadItem requests in embedded G2 as such, i.e. with an additional url param &g2_embed=1. This is just an additional line in the UrlGenerator, because we already check for this case at the right place.
- When handling the (DownloadItem) request, fixCookieVars() would check if this url param is set and if it is the case, it would select the least specific cookie with the name GALLERYSID.

Consequences:
- The url rewrite module would have to cover this case too, i.e. the additional parameter g2_embed needs to be somewhere in the short urls.
A proposed solution from irc:
example.com/g2/d/{itemId}-{serialNumber}-{embed}/image.jpg
whereas {embed} is 1 for embedded DownloadItem urls and not set or 0 for standalone urls.
Right now, short urls have the format foo.com/g2/d/{itemId}-{serialNumber}/image.jpg
example: foo.com/d/121-1-1/IM01.jpg (new embedded urls) vs. foo.com/d/121-1/IM01.jpg (standalone = as before) or foo.com/d/121-1-0/IM01.jpg (new standalone with embed = false set)
- The majority on irc argued, that {embed} shouldn't be optional and also be set (to "0") in standalone for consistency.

Pro's and Con's:
+ relative easy fix
- short urls get uglier and whether it is an embedded request has not much to do with {itemId}-{serialId}
- fixCookieVars v.1 (current G2) was already more complicated than the other fix alternative without this additional changes. Now it gets even worse.
- the auth / cookie fix would be distributed over GallerySession, GalleryUtilities, GalleryUrlGenerator and RewriteUrlGenerator + .htaccess.
I'd prefer a local fix.

Plus the old Pro's and Con's of this approach:
+ fixes all non-array cookies, doesn't need further changes
- dependency on $_SERVER[HTTP_COOKIE], reason unknown that some have it not set on MS IIS webserver (see google for problems)
+ already implemented and unit tests are there
- parsing (time, load), although very lightweight

Fix A:
No changes are needed for fix A. Here again a short summary for this alternative.
- sets the domain to .domain.com unless it's a numerical (IPv4/6) host. in this case, the domain is not set (no subdomains -> no multiple cookies).
- The cookiename should be NAME . substr(md5($galleryId),0,4); because g2dataPath could be equal for multiple installs.

Pro's and Con's:
+ no HTTP_COOKIE dependence
+ robust
+ simple, fixed locally in GallerySession
+ you can take out all the cookie-path stuff to figure out the right path when embedded (something less to maintain)
- hard to identify which cookie is for which site on same domain
- small probability of cookie conflict between sites on same domain
- other cookies must also adopt this naming scheme or have conflict between sites in same domain, i.e. the cookies should go through a function which adds the substr(md5(galleryId), 0, 4).
+ But currently no other cookies in G2 need this. install/ and upgrade/ are only used in standalone, same for /lib/tools/. The javascript cookies of the slider / hybrid layouts are not relevant for the server side of G2.

We could define('SESSION_ID_PARAMETER', 'G2SID' . substr(md5(galleryId), 0, 4)); in config.php then you could identify cookies more easily.
Alternatively, set GALLERYSID in GallerySession.class at the top, but we'd have to assume that the global $gallery object already exists to retrieve the galleryId.

My conclusion:
Fix A is simpler, we'd have less code to maintain and the only real downside are cookie names, that are hard to identify if you have mutiple G2 installs on the same server.
Fix "fixCookieVars v.2" could be implemented in the same time, but has the disadvantage of slightly uglier urls and an ever increasing complexity of the total fix.
Therefore, I vote for fix A.

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2005-05-12 23:56

There seems to be yet another session issue.
This time, I'm not sure if the problem are cookies. I guess the problem lies in G2 session handling.

In some circumstances, when logging in, the first DownLoadItem request right after the the UserLogin view request changes the session back to anonymous!

I couldn't reproduce the issue with G2 debug mode on, so I debugged with other means.

I added some debug output in GallerySession::save. I show 2 images on my main.php page, one album highlight/thumbnail and a random block image. Therefore, when requesting the view/controller Userlogin, there's 1 login request and 2 DownloadItem requests.
After the login request, I'm logged in. After the first DownloadItem request, the exact same cookie and the corresponding session file are for a anonymous user.

the following 3 save sessions are issued when I login into my G2:
1. save session:
request_uri: /gallery2/main.php
sessionId: ab1869e780a772ac1ccd31e0baa2aa34
"core.id.activeUser";i:6; (admin)
...[omitted other session data]

2. save session: debug output:
request_uri: /gallery2/d/74-1/reef5.jpg?g2_GALLERYSID=ab1869e780a772ac1ccd31e0baa2aa34
sessionId: ab1869e780a772ac1ccd31e0baa2aa34
"core.id.activeUser";i:5;
...

// a downloaditem request changed the session from logged in to logged out!!

3. save session: debug output:
request_uri: /gallery2/d/23-2/Reef.jpe?g2_GALLERYSID=ab1869e780a772ac1ccd31e0baa2aa34
sessionId: ab1869e780a772ac1ccd31e0baa2aa34
"core.id.activeUser";i:5;

Steps to reproduce:
1. Have at least show one image on main.php.
2. Login. (eg as admin)
3. Logout.
4. Login again (immediately, you should have navId and galleryId in the address bar of your browser)
5. Now you can either check the g2data/session file for your current sessionid to see that the user has activeUserId 5 (anonymous user) or click on an showitem link (an image link), and you'll see that you're logged out.

 
jgionet
jgionet's picture

Joined: 2005-05-26
Posts: 3
Posted: Thu, 2005-05-26 19:20

is this still and issue with the latest beta2 of g2? I'm having problems login in after upgrading to g2-b2.

System:
WinXP-Pro-Sp2
FF 1.04

Thanks
-JG

 
valiant

Joined: 2003-01-04
Posts: 32509
Posted: Thu, 2005-05-26 19:36

beta 2 is obsolte. beta 3 is about up to date.

the newest cookie fix will be in beta 4.