Mailing List Archive

Quoting Peter (peter@pajamian.dhs.org):
> On 03/04/16 12:25, Peter wrote:
> > This sounds like $::Control is leaking between page requests, are you
> > running Interchange in RPC traffic mode (as set in interchange.cfg)?
>
> Just for a bit of explanation here, when you run Interchange in RPC
> traffic mode child processes are recycled to serve up multiple page
> requests. In doing so certain variables have to be explicitly cleared
> for each page request or they can pick up values from previous pages
> which set those variables. This is done in the reset_vars() sub in
> Server.pm.
>
> What I think is happening is that $::Control is not reset in this
> process, and is picking up values from previous pages that were served
> by the same child process. This would be a bug in Interchange if this
> is the case and needs to be fixed.

I think this would be possible in the case of a new session,
not otherwise.

Probably we should set $::Control as part of init_session.

--
Mike Heins
End Point -- Expert Internet Consulting http://www.endpoint.com/
phone +1.765.253.4194 <mikeh@endpoint.com>

Life isn't fair, but it's good. -- Regina Brett

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Mike Heins (mikeh@endpoint.com):
> Quoting Peter (peter@pajamian.dhs.org):
> > On 03/04/16 12:25, Peter wrote:
> > > This sounds like $::Control is leaking between page requests, are you
> > > running Interchange in RPC traffic mode (as set in interchange.cfg)?
> >
> > Just for a bit of explanation here, when you run Interchange in RPC
> > traffic mode child processes are recycled to serve up multiple page
> > requests. In doing so certain variables have to be explicitly cleared
> > for each page request or they can pick up values from previous pages
> > which set those variables. This is done in the reset_vars() sub in
> > Server.pm.
> >
> > What I think is happening is that $::Control is not reset in this
> > process, and is picking up values from previous pages that were served
> > by the same child process. This would be a bug in Interchange if this
> > is the case and needs to be fixed.
>
> I think this would be possible in the case of a new session,
> not otherwise.
>
> Probably we should set $::Control as part of init_session.

Actually, this should happen in Vend::Server::reset_vars(), and I have
done that. If you apply this patch:

diff --git a/lib/Vend/Server.pm b/lib/Vend/Server.pm
index e31c8f9..52855b3 100644
--- a/lib/Vend/Server.pm
+++ b/lib/Vend/Server.pm
@@ -1240,6 +1240,7 @@ sub reset_vars {
package CGI;
reset 'A-Z';
reset 'a-z';
+ undef $::Control;
undef %Vend::Table::DBI::DBI_connect_cache;
undef %Vend::Table::DBI::DBI_connect_bad;
undef %Vend::Table::DBI::DBI_connect_count;

It should remove the problem. I have committed this to the repository.

--
Mike Heins
End Point -- Expert Internet Consulting http://www.endpoint.com/
phone +1.765.253.4194 <mikeh@endpoint.com>

There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.
-- Mark Twain

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 04/04/16 06:50, Mike Heins wrote:
>> I think this would be possible in the case of a new session,
>> not otherwise.

Possibly also in the case of a "nosession" robot. I did notice that
$::Control is cleared in read_session(), but only if a valid session
actually is read. I think that also this would only really show up if a
control variable is not explicitly set (in the [control-set] tag) for a
page (otherwise the newly set value would override the old), so a fair
few stars have to align properly for this bug to rear its head (which
would be why this hasn't shown up until now).

> Actually, this should happen in Vend::Server::reset_vars(), and I have
> done that. If you apply this patch:

Almost exactly what I was thinking.

> I have committed this to the repository.

Great.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Peter (peter@pajamian.dhs.org):
> On 04/04/16 06:50, Mike Heins wrote:
> >> I think this would be possible in the case of a new session,
> >> not otherwise.
>
> Possibly also in the case of a "nosession" robot. I did notice that
> $::Control is cleared in read_session(), but only if a valid session
> actually is read. I think that also this would only really show up if a
> control variable is not explicitly set (in the [control-set] tag) for a
> page (otherwise the newly set value would override the old), so a fair
> few stars have to align properly for this bug to rear its head (which
> would be why this hasn't shown up until now).
>
> > Actually, this should happen in Vend::Server::reset_vars(), and I have
> > done that. If you apply this patch:
>
> Almost exactly what I was thinking.
>
> > I have committed this to the repository.
>
> Great.

Thanks for finding the bug. In fact, I am wondering if it might be
causing a persistent problem I have seen on another system.

--
Mike Heins
End Point -- Expert Internet Consulting http://www.endpoint.com/
phone +1.765.253.4194 <mikeh@endpoint.com>

The tenor's voice is spoilt by affectation,
And for the bass, the beast can only bellow;
In fact, he had no singing education,
An ignorant, noteless, timeless, tuneless fellow. -- Lord Byron

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

> Quoting Mike Heins (mikeh@endpoint.com):
>> Quoting Peter (peter@pajamian.dhs.org):
>> > On 03/04/16 12:25, Peter wrote:
>> > > This sounds like $::Control is leaking between page requests, are you
>> > > running Interchange in RPC traffic mode (as set in interchange.cfg)?

Just to confirm, yes IC running in RPC mode.

>> Probably we should set $::Control as part of init_session.
>
> Actually, this should happen in Vend::Server::reset_vars(), and I have
> done that. If you apply this patch:
>
> diff --git a/lib/Vend/Server.pm b/lib/Vend/Server.pm
> index e31c8f9..52855b3 100644
> --- a/lib/Vend/Server.pm
> +++ b/lib/Vend/Server.pm
> @@ -1240,6 +1240,7 @@ sub reset_vars {
> package CGI;
> reset 'A-Z';
> reset 'a-z';
> + undef $::Control;
> undef %Vend::Table::DBI::DBI_connect_cache;
> undef %Vend::Table::DBI::DBI_connect_bad;
> undef %Vend::Table::DBI::DBI_connect_count;
>
> It should remove the problem. I have committed this to the repository.

Patch applied to our install and IC restarted. Thank you!

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Quoting Klaatu IC (icgort33@gmail.com):
> > Quoting Mike Heins (mikeh@endpoint.com):
> >> Quoting Peter (peter@pajamian.dhs.org):
> >> > On 03/04/16 12:25, Peter wrote:
> >> > > This sounds like $::Control is leaking between page requests, are you
> >> > > running Interchange in RPC traffic mode (as set in interchange.cfg)?
>
> Just to confirm, yes IC running in RPC mode.
>
> >> Probably we should set $::Control as part of init_session.
> >
> > Actually, this should happen in Vend::Server::reset_vars(), and I have
> > done that. If you apply this patch:
> >
> > diff --git a/lib/Vend/Server.pm b/lib/Vend/Server.pm
> > index e31c8f9..52855b3 100644
> > --- a/lib/Vend/Server.pm
> > +++ b/lib/Vend/Server.pm
> > @@ -1240,6 +1240,7 @@ sub reset_vars {
> > package CGI;
> > reset 'A-Z';
> > reset 'a-z';
> > + undef $::Control;
> > undef %Vend::Table::DBI::DBI_connect_cache;
> > undef %Vend::Table::DBI::DBI_connect_bad;
> > undef %Vend::Table::DBI::DBI_connect_count;
> >
> > It should remove the problem. I have committed this to the repository.
>
> Patch applied to our install and IC restarted. Thank you!

Question is, did the patch fix the problem?

--
Mike Heins
End Point -- Expert Internet Consulting http://www.endpoint.com/
phone +1.765.253.4194 <mikeh@endpoint.com>

An amateur practices until he gets it right. A pro
practices until he can't get it wrong. -- unknown

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Mon, Apr 4, 2016 at 11:50 AM, Mike Heins <mikeh@endpoint.com> wrote:

>> > It should remove the problem. I have committed this to the repository.
>>
>> Patch applied to our install and IC restarted. Thank you!
>
> Question is, did the patch fix the problem?

This might take time to confirm as the issue is hard to reproduce. I
have never come across the issue in the time I have used IC and only
saw this anomaly in a screen grab emailed to me from the site owner. I
will hammer test the site from various IPs/fresh browsers and also ask
the site owner to see if they can reproduce it. If we can get it to
break I'll reply to this thread.

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On 04/04/16 13:50, Mike Heins wrote:
> Question is, did the patch fix the problem?

That's going to be difficult to test. The most reliable way to test it
(that I can think of) would be the following:

Page "A" would be the page that the data is leaking *from*.

Page "B" would be the page that the leaked data is appearing on where it
shouldn't.

Wait until a very low-traffic time to run this test.

Drop the "StartServers" down to a really low value in interchange.cfg
and restart IC.

Use wget or curl in a loop to pound page "A" continuously during the
test, this will ensure that the data gets stashed in the child processes
as much as possible.

Repeatedly dump cookies and then fetch page "B" in your browser while
this is happening, watch for the data to get leaked to this page.

Do the above both with and without Mike's patch and compare results.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users

On Mon, Apr 4, 2016 at 12:35 PM, Peter <peter@pajamian.dhs.org> wrote:

> That's going to be difficult to test. The most reliable way to test it
> (that I can think of) would be the following:

Snipped for brevity.

> Do the above both with and without Mike's patch and compare results.

Ok I have created the test pages in seperate catalogs and will advise
results if anything meaningful occurs.

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users