Cidram: How to correctly hook CIDRAM to OpenCart

[gizmecano]

CIDRAM version used

1.17.3 96fb9931cd4eb1804fa024ad95883817b3df4cb3

PHP version installed

5.6.40

---

In writing my previous issue #184 , I was presumptuous in stating that:

I think I have implemented the system correctly as various log files are effectively created and give a list of blocked connections.

In fact, CIDRAM seems not to correctly be "hooked" to OpenCart: indeed, since it has been installed, some orders manipulations aren't possible anymore. The front-end of Opencart gives the following error:

SyntaxError: JSON.parse: 
unexpected end of data at line 1 column 1 of the JSON data

I digged about the causes of such an error which isn't totally unknown (maintenance mode active, user API issue, etc). I have tested various of these known possible origins without success, when I came to the following point in a checklist:

Check if you have added any $_SERVER['REMOTE_ADDR'] into an if block to reject ips on purpose

At this point, I have suddenly considered that the recent installation of CIDRAM can be the main cause of this error. I commented the hook I had manually added in the main index.php (just before requiring VQMOD) at the root of the installation and (_alas_) this patch resolved the error.

As the documentation states that _if you encounter difficulties in working this out for yourself, visit the CIDRAM issues page_, I open this second issue to looking for solutions:

Does anyone know how to correctly hook CIDRAM to OpenCart without causing this kind json of error? Is it appropriate to embed the "hook" in an other page than index.php or is it practicable to use a specific position in this main page?

Thanks.

[gizmecano]

I (partially) cross-posted this issue on _Stackoverflow_ to increase the chances of obtaining a possible variety of proposed solutions.

[Maikuolan]

In fact, CIDRAM seems not to correctly be "hooked" to OpenCart: indeed, since it has been installed, some orders manipulations aren't possible anymore. The front-end of Opencart gives the following error:

SyntaxError: JSON.parse: 
unexpected end of data at line 1 column 1 of the JSON data

As long as CIDRAM doesn't block such requests, it shouldn't cause those kinds of errors (because CIDRAM shouldn't produce any kind of output at all except when something is blocked, or when using the front-end).

But, since CIDRAM produces its output as pure HTML, if CIDRAM is blocking those JSON requests, it definitely could potentially cause those kinds of errors (since OpenCart would be expecting a JSON-formatted response from its orders system, but is instead seeing the HTML-formatted response from CIDRAM).

I think, the best course of action at this time, would be to try confirming whether CIDRAM is blocking those JSON requests. If we confirm that it is blocking them, then we can write some simple bypasses to ensure that it won't block them anymore (and that would also suggest that you've most likely hooked it correctly, and that the hooks aren't the problem). If we confirm that it isn't blocking them, then.. it's possible that CIDRAM hasn't been hooked correctly, or that there might be some kind of bug which we didn't know about before.

It should be possible to confirm by ensuring that logging is enabled, reproducing the error by attempting some more order manipulations, and then checking the log files, to try cross-referencing some log entries with the specific requests at the orders system where the errors occurred (e.g., log entries with "reconstructed URIs" which match something belonging to the orders system, or with dates/times which align with the approximate date/time when the error occurred, and an originating IP address which matches either your own IP address, or the IP address of your server). If there are cross-referenced log entries, that's our evidence that CIDRAM is blocking the requests. If there aren't any log entries, most likely CIDRAM isn't blocking the requests (assuming, of course, that logging is working correctly at the time).

[gizmecano]

@Maikuolan

Thank you for this very detailed response, once again. Based on your comments above, I will therefore try to organize a series of tests to assess the problem as well as possible. I will then report my observations.

[gizmecano]

@Maikuolan wrote:

If we confirm that it is blocking them, then we can write some simple bypasses to ensure that it won't block them anymore (...)

I followed the test process you mentioned above. I can confirm that CIDRAM is blocking these inner requests. For example, the Apache log has saved some of my manipulation attempts, such as:

[Wed, 22 Jul 2020 13:44:30 +0200] "POST /index.php?route=api/login HTTP/1.1" 200 3504 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0"
[Wed, 22 Jul 2020 13:52:14 +0200] "POST /index.php?route=api/login HTTP/1.1" 200 3504 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0"

Then, I noticed the IP mentionned in the log (and not pasted above) isn't the IP of the main website I can check if I use a tool such as Flagfox. I tested this specific IP in the CIDRAM front-end and discovered that it is considered as a a _cloud_ service.

Therefore, following the answer you gave to the issue #118, I read the content of the ipv4_custom.dat.RenameMe file and create my own ipv4_custom.dat in order to unblock this specific IP which is used by the back-office of the site.

After uploading the file and updating the main configuration of CIDRAM, I checked the front-end and the IP is no more announced as blocked. I tested again some back-office manipulations and, this time, I didn't encountered the previous json warning.

(and that would also suggest that you've most likely hooked it correctly, and that the hooks aren't the problem).

Yes, actually CIDRAM is _a priori_ well "hooked" since the logs seem to record all operations (including on the back-office). Perhaps I should have titled my issue differently (but that was the first idea that came to my mind).

I still leave this issue opened the time to check that everything is working well and that the "hooking" is totally faultless.

Thanks.

[gizmecano]

As the creation of a customized ipv4_custom.dat file seems to confirm that the problem was due to an _untimely_ blocking of an address used internally and not to any hooking problem, I suppose this issue can be closed for the moment.

Thanks for your attention. 👍

[Maikuolan]

You're most welcome, and I'm glad to hear that the problem has been resolved. :-)