Ceon URI Mapping V5.0

[torvista]

https://github.com/zencart/zencart/issues/4939

I also did if (!defined

I have this mod working in production with ZC158, but since I have the UMM version, I can't make my changes public.
I invested a lot of time keeping this mod alive in the interim between Conors passing and CEON support being reactivated. I'm not doing that again.

CEON support needs to clarify the support plan for the free mod.

[strelitzia]

If you would set one up, that would be great, I have some fixes as well and I'm sure others do.

If CEON Support hasn't been responsive over several months, we'll need to proceed on our own.

Hi Scott,

Apologoes this has taken a while to get round to. I've been busy of late as I've recently taken over JSWeb.
Anyway, here's the GitHub link for CEON URI MAPPING

https://github.com/JSWebSteve/Ceon-URI-Mapping-V5.1.0

[torvista]

@Strelitzia
I have forked your repository and pushed my changes for ZC158/php8.2 to my fork.

[neekfenwick]

Can I ask, @torvista or anyone here, what you do about EZ pages, if anything? I just ran into ezpage URLs not working in my 1.5.8 upgrade, I traced it to the fact that URIMappingHandler basically sets $_GET['id'] = (int)$associated_db_id, and later sanitize.php checks with a strict ctype_digit test, so an integer value in $_GET['id'] is discarded, and the ez page header.php gets an empty $ezpage_id and panic redirects to the home page.

This change seems to have come in from lat9 pull #4954 here 4 months ago https://github.com/zencart/zencart/p...9eb3e460775e64

Your fork doesn't appear to address this issue. I'm guessing you don't use EZ pages :) My Mickey Mouse fix is to hack the URIMappingHandler to set $_GET values to strings instead of integers, i.e.: $_GET['id'] = "$associated_db_id";

[torvista]

I'm guessing you don't use EZ pages

Correct. Sorry.

[mc12345678]

Can I ask, @torvista or anyone here, what you do about EZ pages, if anything? I just ran into ezpage URLs not working in my 1.5.8 upgrade, I traced it to the fact that URIMappingHandler basically sets $_GET['id'] = (int)$associated_db_id, and later sanitize.php checks with a strict ctype_digit test, so an integer value in $_GET['id'] is discarded, and the ez page header.php gets an empty $ezpage_id and panic redirects to the home page.

This change seems to have come in from lat9 pull #4954 here 4 months ago https://github.com/zencart/zencart/p...9eb3e460775e64

Your fork doesn't appear to address this issue. I'm guessing you don't use EZ pages :) My Mickey Mouse fix is to hack the URIMappingHandler to set $_GET values to strings instead of integers, i.e.: $_GET['id'] = "$associated_db_id";

There is also the following known issue with ez pages in the released version of Zen Cart 1.5.8: https://www.zen-cart.com/showthread....72#post1390772

Why the core code was changed to necessitate the values to be a string in order to validate that the string is made of numbers seems silly to me. Instead of removing the cast to an integer, why not then cast it to a string?

[neekfenwick]

Apologoes this has taken a while to get round to. I've been busy of late as I've recently taken over JSWeb.
Anyway, here's the GitHub link for CEON URI MAPPING

https://github.com/JSWebSteve/Ceon-URI-Mapping-V5.1.0

@strelitzia Hi, are you a Ceon support rep, and is this the official Ceon URI Mapping repo, and can we issue Pull Requests? Or if not there, then where? The repo doesn't seem to be forked from anywhere, but also the files don't have much history so it seems to have been borrowed rather than formally developed. It would be nice to be able to feed useful code fixes back to the addon.

First, I'd like to see a little discussion as @mc12345678 mentioned, why the init_sanitize code works the way it does. I presume the logic behind using ctype_digit() is that a $_GET parameter _ought_ to have come in via a query parameter, which _ought_ to only be able to be text, so any non-string data _probably_ is a hack, but this seems rather tenuous logic and I don't know of any spec that defines what data type $_GET parameters may be. It is amusing that products_id is not sanitised (it's not in the array of fields to check), so URIMappingHandler can set $_GET['products_id'] = 123 without problems, which is possibly why this 'bug/feature' hasn't been noticed before since it doesn't affect product pages.

[swguy]

> First, I'd like to see a little discussion as @mc12345678 mentioned, why the init_sanitize code works the way it does.
Please open an issue on Github.

https://github.com/zencart/zencart

[mc12345678]

It is amusing that products_id is not sanitised (it's not in the array of fields to check), so URIMappingHandler can set $_GET['products_id'] = 123 without problems, which is possibly why this 'bug/feature' hasn't been noticed before since it doesn't affect product pages.

The parameter products_id is not strictly an integer because many, many years ago, it was determined that the products_id would be used to support carrying the attribute information related to the product.

Not everyone uses attributes in every store, so yes, it may in part be possible that a store could operate with such integer sanitization. But, the broader use of the field is numerical and whatever character(s) result from hashing the attributes separated by a colon.

In a way that hashing can be useful to recreate the product, though nearly falls apart when the product has an attribute allowing user provided text.

[neekfenwick]

Please open an issue on Github.

Fair point, thanks. https://github.com/zencart/zencart/issues/5366