Not logged in. · Lost password · Register
Forum: Support › Bug reports and troubleshooting RSS
Cannot create posts in fresh install?
Pompei2 2010-05-12, 12:30 #1
Member since Mar 2010 · 17 posts
Group memberships: Members
Show profile · Link to this post
Subject: Cannot create posts in fresh install?
Hi,

On my production server (UNB 20090606-dev, PHP 5.2.11, Apache 2.2.10, OpenSuse 11.1, MySQL 14.12 distrib 5.0.67), the board works just well.

I installed a LAMP environment on my notebook (latest unb, PHP 5.3.1, Apache 2.2.13, OpenSuse 11.2, MySQL 14.14 distrib 5.1.36) for testing purposes. Everything works well (after applying the patch for PHP 5.3 I sent you in the other thread) and I run the installation of the board with success. I create a (sub-)forum, that works too. Creating anything of type "Post" (i.e. a new thread, but also an announcement) does not work:

Preview works, but posting it doesnt, no error message, just the form that comes back all empty. I tried to debug it and recognized that it is because UnbUrlCheckKey returns false. Cookies are enabled in my browser and I use exactly the same one as for visiting the production server, so it's not the browser's fault.

In fact, I then realized that everytime I Click on post again, my session_id has changed! Thus it's not the same than in the hidden "key" form element.

I have absolutely no clue why this is. May it be because of some change in the new php version? Or is it the LAMP env on my notebook that is misconfigured? (although I compared both php.ini files' session settings!) Any help whatsoever is appreciated.
This post was edited on 2010-05-12, 12:39 by Pompei2.
Edit reason: Added note about unb version
Avatar
Yves (Administrator) 2010-05-12, 19:24 #2
User title: UNB developer & webmaster
Member since Jan 2004 · 3855 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I can create a new thread in my development environment which should be in about the same state as your version regarding the latest changes. It's not usual that your session ID doesn't persist across two requests. In fact this makes using the session impossible and therewith a lot of UNB functions. Do you think you could investigate whether the session cookie is correctly sent out by the web server, received in your browser and then sent out again? You could use the Firefox add-on "Live HTTP headers" to see that. Maybe the session cookie uses a wrong URL path?
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Pompei2 2010-05-13, 14:11 #3
Member since Mar 2010 · 17 posts
Group memberships: Members
Show profile · Link to this post
I did my best, using the "Firebug" add-on (awesome one, try it out!) and this is what I have observed:

skip this and read below starting from "Edit 2" to see a possible solution and suggestion on how unb can avoid such problems.
Anyway, thanks a lot for your patience Yves.

When I'm logged-in, this happens in any page of the forum (not only new post):

  • The cookie called "UnbUser-unb430":
    • stays the same, no matter where I go and what I do (besides logging-out of course).
    • Has the forum "1+some long hex number"

  • The cookie called "unb430sess":
    • Changes with every new pageload.
    • Is just some long hex code.
    • Say, I am looking at a page and right now the cookie has the value "AB". When I reload the page, the cookie still has the value "AB" in my request, but in the answer from the server (here: localhost), it has a new value, say "CD". And every time again..

Unfortunately, I don't know how I can interpret these observations?

Oh by the way, both have "Path=/unb/", the persistent one (UnbUser-unb430) has "expires=" set to tomorrow, while the one that always changes (unb430sess) has no "expires" set. But it has a "HttpOnly" flag.

May it be because the second one has no "expires" set, that it always changes? Where does it come from? Who generates these values, apache, php or unb?

Maybe the session cookie uses a wrong URL path?
This, I don't understand/don't know how to verify. That's why I show you the full experiment below:

Request:
GET /unb/forum.php?req=search HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.2.3) Gecko/20100401 SUSE/3.6.3-1.2 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/unb/forum.php
Cookie: UnbUser-unb430=1+21232f297a57a5a743894a0e4a801fc3; unb430sess=89468e6fb5f884fa1382180f799f8ef6; unb734sess=8ce12e973c9ecf81d0b20d56806e8f5d

Answer:
HTTP/1.1 200 OK
Date: Thu, 13 May 2010 11:56:27 GMT
Server: Apache/2.2.13 (Linux/SUSE)
X-Powered-By: PHP/5.3.1
Set-Cookie: unb430sess=8320650bdf3b8b3e4a536407e88427bc; path=/unb/; HttpOnly
UnbUser-unb430=1+21232f297a57a5a743894a0e4a801fc3; expires=Fri, 13-May-2011 11:56:27 GMT; path=/unb/
Expires: Thu, 13 May 2010 13:56:27 +0200
Cache-Control: no-cache
Pragma: no-cache
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8


Then comes the click on refresh, then:

Request:
GET /unb/forum.php?req=search HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fr; rv:1.9.2.3) Gecko/20100401 SUSE/3.6.3-1.2 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://localhost/unb/forum.php
Cookie: UnbUser-unb430=1+21232f297a57a5a743894a0e4a801fc3; unb430sess=8320650bdf3b8b3e4a536407e88427bc; unb734sess=8ce12e973c9ecf81d0b20d56806e8f5d
Cache-Control: max-age=0

Answer:
HTTP/1.1 200 OK
Date: Thu, 13 May 2010 12:07:27 GMT
Server: Apache/2.2.13 (Linux/SUSE)
X-Powered-By: PHP/5.3.1
Set-Cookie: unb430sess=380781f9e7e7b80b9b33a3badffac92e; path=/unb/; HttpOnly
UnbUser-unb430=1+21232f297a57a5a743894a0e4a801fc3; expires=Fri, 13-May-2011 12:07:27 GMT; path=/unb/
Expires: Thu, 13 May 2010 14:07:27 +0200
Cache-Control: no-cache
Pragma: no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8



I really need your help :)


Edit: I just tried that out on your forum here at unclassified.de. What I found interesting is that here I don't get a "Set-Cookie:" field in the answer at all! Maybe this is the problem, that I have that line. do you have an idea where it may come from?


Edit 2 - solution:
In fact, on my localhost dev server, the cookies do not appear in the php $_REQUEST variable! In the production server, they do! So, the "unb430sess" entry in $_REQUEST is missing and thus the UnbCheckSession creates a new session ID.

The question boils down to: "why are the cookies not present in the $_REQUEST array?"

The answer is given in a comment in the php reference. Starting from PHP 5.3, it is configurable what appears in that array, and some systems default to not including the cookies.

A simple solution for Unb would be to avoid the $_REQUEST variable and rather use the $_COOKIE variable when reading a cookie. (And $_POST and $_GET for forms and arguments respectively.) I have tested that and it now works on my localhost without having to change any configuration.
This post was edited on 2010-05-13, 14:38 by Pompei2.
Edit reason: Solution!
Avatar
Yves (Administrator) 2010-05-13, 18:38 #4
User title: UNB developer & webmaster
Member since Jan 2004 · 3855 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Quote by Pompei2:
Request:
GET /unb/forum.php?req=search HTTP/1.1
(...)

Answer:
(...)
Set-Cookie: unb430sess=8320650bdf3b8b3e4a536407e88427bc; path=/unb/; HttpOnly
UnbUser-unb430=1+21232f297a57a5a743894a0e4a801fc3; expires=Fri, 13-May-2011 11:56:27 GMT; path=/unb/

This says that the cookie path is set correctly.

I just tried that out on your forum here at unclassified.de. What I found interesting is that here I don't get a "Set-Cookie:" field in the answer at all!

Maybe you don't get cookies all the time because you got one at the beginning of your session and the cookie stuff works on my server.

The answer is given in a comment in the php reference. Starting from PHP 5.3, it is configurable what appears in that array, and some systems default to not including the cookies.

A simple solution for Unb would be to avoid the $_REQUEST variable and rather use the $_COOKIE variable when reading a cookie. (And $_POST and $_GET for forms and arguments respectively.) I have tested that and it now works on my localhost without having to change any configuration.

That looks interesting. Although I wasn't aware that I'd be using $_REQUEST for stuff that I know of it's in a cookie, but I'll look into it again.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
jense 2010-05-14, 23:18 #5
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
That looks interesting. Although I wasn't aware that I'd be using $_REQUEST for stuff that I know of it's in a cookie, but I'll look into it again.
The safe way is to regenerate $_REQUEST from $_GET, $_POST and $_COOKIE in common.lib.php (right after the gpc clean up). It has always been configurable and this really sucks in PHP...
Alala, Alala, Gimme three wishes - CSS
Avatar
Yves (Administrator) 2010-05-15, 21:36 #6
User title: UNB developer & webmaster
Member since Jan 2004 · 3855 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Yes, it's like hacking up PHP... :-D That would be the quick and dirty way. Maybe I can come up with something else. Maybe not.

You mean the php.ini setting "request_order" which has no default value but seems to include GET and POST but not COOKIE. Actually, I need to use $_COOKIE whenever I access cookies which should always be clear.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
jense 2010-05-15, 21:39 #7
Member since Nov 2006 · 327 posts · Location: Dortmund
Group memberships: Members
Show profile · Link to this post
Quote by Yves:
That would be the quick and dirty way.
... and predictable... — this shouldn’t be configurable!
Alala, Alala, Gimme three wishes - CSS
Avatar
Yves (Administrator) 2010-05-16, 12:08 #8
User title: UNB developer & webmaster
Member since Jan 2004 · 3855 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
In reply to post #4
Quote by Yves on 2010-05-13, 18:38:
That looks interesting. Although I wasn't aware that I'd be using $_REQUEST for stuff that I know of it's in a cookie, but I'll look into it again.

Fixed in session.lib.php. If there are other places, please let me know. The session ID is now persistent again with request_order=GP.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:

Go to forum
This board is powered by the Unclassified NewsBoard software, 20120620-dev, © 2003-2011 by Yves Goergen
Page created in 223 ms (167.9 ms) · 92 database queries in 121.7 ms
Current time: 2013-05-18, 13:51:24 (UTC +02:00)