10.0.3 Site errors for logged in customers

[jmedinger]

Have just patched a site to 10.0.3 (from v10) and we are getting an error in the error.err file every time a logged in customer clicks through to a product page from a search.

Internal Errors = The requested file (Tumbled_stones.html#a32_2d096) is outside the scope of the script. If you believe the requested page should be served please contact the site operator.

This seems to be a 'soft' error in that it doesn't affect the page the customer is sent to (or seeing) but has only started happening after the upgrade to v10.0.3

Can anyone shed any light on whether this is an issuethat needs fixing?

[NormanRouxel]

As always, URL? And test login credentials would be useful too.

[jmedinger]

Sorry Norman...

It's Machester Minerals

Test Login
User : test@test.com
Pass : test

It might be 5mins before the new test account is published to the site

[NormanRouxel]

This looks like a bug introduced when Actinic have added some security checking into Actinic.pm in sub CheckSafeFilePath. This checks files that are to be processed and makes sure that a file / anchor pair are valid and the file only refers to files within acatalog or the site root.

Now the Search results links for some reason are including the anchor twice, once with escaped data and another with a plain # character. E.g.

?REFPAGE=http%3a%2f%2fwww.manchesterminerals.co.uk%2fcgi%2fbb000014.pl%3fPRODUCTPAGE%3dTumbling_Machines.html&WD=silver&PRODUCTPAGE=Brooches__Not_Stone_set_.html%23a1_2181_2d085#a1_2181_2d085

Here's the relevant bit shortened for clarity:

Brooches__Not_Stone_set_.html%23a1_2181_2d085#a1_2181_2d085

I've marked the escaped # in red and the standard one in green.

I've no idea why the search results bungs in two anchors but have a feeling that it has done this for ages and it may only be causing errors due to the upgraded security checking.

The CheckSafeFilePath splits the file into name and anchor using # as the delimiter. However the escaped first anchor mean that the first # isn't detected (as it's actually %23) and the filename ends up with that first anchor attached to it, thus the invalid file error as it now looks for a file called Brooches__Not_Stone_set_.html%23a1_2181_2d085.

So the problem is either the search results adding two anchors (one with an escaped #) or CheckSafeFilePath not checking for escaped anchors. Maybe both!

One really for Actinic to comment on and fix.

[NormanRouxel]

I could write a workaround but would rather not tinker with code that's security related.

I've posted this as a bug report and linked to this thread. It would be useful if you could leave that login active until someone at the Towers has had a chance to look.

[jmedinger]

No probs - we'll leave the test account live (it's set to retail prices anyway)

[Benjamin Dyer]

No probs - we'll leave the test account live (it's set to retail prices anyway)

Hi, have you raised a ticket for this?

Thanks,

Ben

[jmedinger]

Benjamin

No... sorry I was under the impression that the bug report Norman posted would have done this...

Do I still need to do this?

[Duncan Rounding]

You should still raise a support ticket - you can reference this thread in it.

[NormanRouxel]

If anyone's interested it's this little bock of code in SearchScript.pl that's doing it.

if ($$::g_pSearchSetup{SEARCH_SHOW_HIGHLIGHT} &&	# the words are to be highlighted
	 $sSearchStrings)								# and there are some words
	{
	$Product{ANCHOR} =~ /([^\#]*)(.*)/;		# break the page into the file and anchor
	my $sAnchor = $2;
	$ACTINIC::B2B->SetXML('S_LINK', sprintf('<A HREF="%s">', $sScript . ACTINIC::EncodeText2($Product{ANCHOR}, $::FALSE) . $sAnchor));
	}
else													# the links to the products are direct (no highlighting)
	{
	$ACTINIC::B2B->SetXML('S_LINK', sprintf('<A HREF="%s">', $Product{ANCHOR}));
	}

I've marked the bit that duplicates the anchor in red.

The problem only happens if you choose Highlight Located Text in Settings / Site Options / Search Settings / Results. So turning that off will help.

A possible fix would be to replace (untested):

	$ACTINIC::B2B->SetXML('S_LINK', sprintf('<A HREF="%s">', $sScript . ACTINIC::EncodeText2($Product{ANCHOR}, $::FALSE) . $sAnchor));

With:

	$ACTINIC::B2B->SetXML('S_LINK', sprintf('<A HREF="%s">', $sScript . ACTINIC::EncodeText2($1, $::FALSE) . $sAnchor));

As this would do what the comments suggest is intended.

[jmedinger]

Norm

Thanks for this - it seems to have resolved that particular issue... I think we've found another place it's manifesting...

When you click on a bestseller, it takes you to the correct page but doesn't then pull you to the anchor for the product.

On looking at the URL generated, there are 2 hashes being created, one as a '#' and the other as a '%23'

Is this anything to do with this line

$sCgiUrl   .= ($::g_InputHash{SHOP} ? '?SHOP=' . ACTINIC::EncodeText2($::g_InputHash{SHOP}, $::FALSE) . '&': '?');

in actinic.pm?