User logged out after *every* action?

RT Users
1

Hi,
I have rt 3.8.7 working on one server, and it’s working fine.

Now, I installed 3.8.8 on another server (from sources), copied config,
and modified it to connect to correct database.

When I go to new server - it shows correct 3.8.8 page, I can login, and
all seems to work.

Until I click on any link.

Any click takes me back to login screen. When I do login - I am shown
the page I requested before. Another click, another login screen.

Tried stracing, checking sessions table in database (it does contain the
data), tcpdumping traffic.

I have no idea what might be wrong.

I know that I probably didn’t give any sensible information in here, but
will be more than happy to answer any questions you might have that will
push me closer to solving my problem - after all, re-logging in after
every click is hardly good thing.

as for my setup.

I have nginx in front, with this config:

server {
server_name some_server;
listen 80;
charset utf-8;
access_log /var/log/nginx/some_server.access.log combined_with_time;
error_log /var/log/nginx/some_server.error.log;

location / {
    root   /opt/rt3/share/html;
    fastcgi_pass  127.0.0.1:50004;
    fastcgi_param  QUERY_STRING       $query_string;
    fastcgi_param  REQUEST_METHOD     $request_method;
    fastcgi_param  CONTENT_TYPE       $content_type;
    fastcgi_param  CONTENT_LENGTH     $content_length;
    fastcgi_param  PATH_INFO          $fastcgi_script_name;
}
location /NoAuth/ {
    alias /opt/rt3/share/html/NoAuth/;
}

}

As I said - aside form this relogging after every click - everything seems to work.

Best regards,

depesz

Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

2

Hi,
I have rt 3.8.7 working on one server, and it’s working fine.

ok. did some more tests, and found the solution.

So. my 3.8.8 is on PostgreSQL 9.0, while 3.8.7 was on 8.4.

The problem with 9.0 is that it changes default bytea encoding.

And bytea is used to store session data:
$ \d sessions
Table “public.sessions”
Column | Type | Modifiers
id | character(32) | not null
a_session | bytea |
lastupdated | timestamp without time zone | not null default now()
Indexes:
“sessions_pkey” PRIMARY KEY, btree (id)

up to PostgreSQL 8.4, when you had a_session data being string ‘depesz-ąć’, it was returned like this:
depesz-\304\205\304\207
but
from PostgreSQL 9.0 default encoding for bytea fields is hex. And the same bytea value is now returned as:
\x64657065737a2dc485c487

just so that we are clear - this is the same value - 11 bytes, but it’s encoded differently.

Apparently rt doesn’t handle hex encoding, and when postgresql was returning hex-encoded bytea values - it didn’t know what to do with it.

I.e. rt was storing values encoded using old method (named “escape”), but was given back hex-encoded values.

So. The simple solution is to do this:
set bytea_output = ‘escape’;
in the beginning of every database connection.

Alternatively, we can do this, once:
alter user rt set bytea_output = ‘escape’;
this will change default value of bytea_output (encoding type) for every
new connection using user rt.

Alternatively - we could/should teach rt to understand hex-encoded bytea
values.

Actually, hex-encoded values are very simple to encode/decode, and
basically we should do something like:

if ( $value =~ s/\A\x// ) {

This is hex encoding

$value =~ s/(..)/chr hex $1/ge;

} else {
# in here should go previous decoding code
}

Best regards,

depesz

Linkedin: Hubert Lubaczewski - Instructure, Inc. | LinkedIn / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

3

There’s a patch in rt git for this.“hubert depesz lubaczewski” depesz@depesz.com wrote:

On Sat, Dec 11, 2010 at 11:33:49PM +0100, hubert depesz lubaczewski wrote:

Hi,
I have rt 3.8.7 working on one server, and it’s working fine.

ok. did some more tests, and found the solution.

So. my 3.8.8 is on PostgreSQL 9.0, while 3.8.7 was on 8.4.

The problem with 9.0 is that it changes default bytea encoding.

And bytea is used to store session data:
$ \d sessions
Table “public.sessions”
Column | Type | Modifiers
-------------±----------------------------±-----------------------
id | character(32) | not null
a_session | bytea |
lastupdated | timestamp without time zone | not null default now()
Indexes:
“sessions_pkey” PRIMARY KEY, btree (id)

up to PostgreSQL 8.4, when you had a_session data being string
‘depesz-ąć’, it was returned like this:
depesz-\304\205\304\207
but
from PostgreSQL 9.0 default encoding for bytea fields is hex. And the
same bytea value is now returned as:
\x64657065737a2dc485c487

just so that we are clear - this is the same value - 11 bytes, but it’s
encoded differently.

Apparently rt doesn’t handle hex encoding, and when postgresql was
returning hex-encoded bytea values - it didn’t know what to do with it.

I.e. rt was storing values encoded using old method (named “escape”),
but was given back hex-encoded values.

So. The simple solution is to do this:
set bytea_output = ‘escape’;
in the beginning of every database connection.

Alternatively, we can do this, once:
alter user rt set bytea_output = ‘escape’;
this will change default value of bytea_output (encoding type) for
every
new connection using user rt.

Alternatively - we could/should teach rt to understand hex-encoded
bytea
values.

Actually, hex-encoded values are very simple to encode/decode, and
basically we should do something like:

if ( $value =~ s/\A\x// ) {

This is hex encoding

$value =~ s/(…)/chr hex $1/ge;
} else {

in here should go previous decoding code

}

Best regards,

depesz

–
Linkedin: Hubert Lubaczewski - Instructure, Inc. | LinkedIn / blog:
http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl /
gg:6749007

4

There’s a patch in rt git for this.

ah. too bad I didn’t know.

thanks,

Best regards,

depesz

Linkedin: Hubert Lubaczewski - Instructure, Inc. | LinkedIn / blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007