I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I’m not sure which fix you’re referencing, since my sha1 in that
thread was for the 3.6 fix, which was a backport of
84022062cec889f1cabf1d4a10e28b7b66addf23 from 3.8
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I’m not sure which fix you’re referencing, since my sha1 in that
thread was for the 3.6 fix, which was a backport of
84022062cec889f1cabf1d4a10e28b7b66addf23 from 3.8
tie %session, ‘RT::Interface::Web::Session’, undef;
+}
if ( int RT->Config->Get(‘AutoLogoff’) ) {
my $now = int(time/60);
my $last_update = $session{‘_session_last_update’} || 0;
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I’m not sure which fix you’re referencing, since my sha1 in that
thread was for the 3.6 fix, which was a backport of
84022062cec889f1cabf1d4a10e28b7b66addf23 from 3.8
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I’m not sure which fix you’re referencing, since my sha1 in that
thread was for the 3.6 fix, which was a backport of
84022062cec889f1cabf1d4a10e28b7b66addf23 from 3.8
Again, not sure what fix you applied, so it’s hard to comment further.
-kevin
It was the 3.8 session fixation patch.
So, that fixed the double login or caused it?
-kevin
It caused it. I removed the second half of the test in the unless
just like the mention in the thread. Then it worked again, but
with what consequences?
I am investigating a problem with the SelfService login page where
unprivileged users must login two times in a row for it to succeed.
I found this thread:
and I think that my issue is the same. Unfortunately, I cannot
find the original patch for 3.8.0 - 3.8.5 that I applied. Does
anyone have a copy of the patch or an idea on how to debug this.
Regards,
Ken
I had to make the same change to:
share/html/Elements/SetupSessionCookie
as described in the thread to eliminate the double login.
Like the original thread, I am curious if there is a problem
with this fix or a better one? I am running 3.8.5.
I’m not sure which fix you’re referencing, since my sha1 in that
thread was for the 3.6 fix, which was a backport of
84022062cec889f1cabf1d4a10e28b7b66addf23 from 3.8
Again, not sure what fix you applied, so it’s hard to comment further.
It was the 3.8 session fixation patch.
So, that fixed the double login or caused it?
It caused it. I removed the second half of the test in the unless
just like the mention in the thread. Then it worked again, but
with what consequences?
That change should be fine.
The actual 3.8.6 (which contains a fix) completely rewrites the code
path. Unfortunately, it’s hard to comment more on a patch from 2009
without a lot more digging.
Again, not sure what fix you applied, so it’s hard to comment further.
It was the 3.8 session fixation patch.
So, that fixed the double login or caused it?
It caused it. I removed the second half of the test in the unless
just like the mention in the thread. Then it worked again, but
with what consequences?
That change should be fine.
The actual 3.8.6 (which contains a fix) completely rewrites the code
path. Unfortunately, it’s hard to comment more on a patch from 2009
without a lot more digging.
-kevin
I understand and thank you for taking a quick look. We have an update
to 3.8.10 scheduled.