Errors when bot supplies its own session ID? |
I've got a new hook that logs my php and mysql errors, then emails them to me every ten minutes. It's only been in place for the last 12 hours, and I'm seeing Baiduspider causing some errors, but not sure what is going on. Take a look at the log entry:
Code: THIS IS THE PHP ERROR WITH REQUEST HEADERS SHOWING BAIDUSPIDER: Now, I know in my application code that nowhere am I just blindly allowing people to supply their own session IDs, and entering them into the database as a valid session ID, so I'm wondering if this is the way CI sessions is supposed to work? In the header it appears that Baiduspider is supplying a session ID, but in the MySQL error it looks like the session already exists and is expired. In a normal browser the expired session would be dropped, and this problem wouldn't exist, but why does CI blindly want to enter the session into the sessions table? In the database I see the session with matching Id, and it has a timestamp a second or two before these errors: 1463844797 Enlighten me ....
I can reproduce this error by running this a few times via CLI:
PHP Code: <?php
Brian, I can't address the internal function of CI, but this may be caused by baiduspider requesting a second load of your page. First request via your url and then a second request via some other function?
Just a guess. It is only this one spider that produces the error, right?
CI 3.1 Kubuntu 19.04 Apache 5.x Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing. Clarity is desirable over Brevity every time. (05-24-2016, 09:16 AM)twpmarketing Wrote: Brian, I can't address the internal function of CI, but this may be caused by baiduspider requesting a second load of your page. First request via your url and then a second request via some other function? No. Googlebot, bingbot, Yahoo slurp, Majestic, etc, etc. The issue is that they keep reusing the same session ID, and they are bots so they are too stupid to update the session ID. When they send the same session ID twice, CodeIgniter can't handle that because for some reason CI thinks it needs to insert a new record in the database, but it already exists. I can blacklist a bot from sessions, but maybe there is a better solution from Narf or somebody else. This issue is only new for me because I started using a custom error handler that sees these errors on production. I'm kicking myself because this could have been happening for many months since I upgraded to CI3, or maybe even longer.
Ok, I'll follow this and hope to learn what causes the glitch.
Thanks
CI 3.1 Kubuntu 19.04 Apache 5.x Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing. Clarity is desirable over Brevity every time.
Another thing that is strange is that it isn't happening on the dev server with PHP7.
Is your dev server connected to the net? Mine is totally local, so I don't see outside traffic until I do the upload to a live server.
CI 3.1 Kubuntu 19.04 Apache 5.x Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing. Clarity is desirable over Brevity every time. (05-24-2016, 10:40 AM)twpmarketing Wrote: Is your dev server connected to the net? Mine is totally local, so I don't see outside traffic until I do the upload to a live server. No, it's just local. I'm just running my script locally, and not sure if that's why there's a difference. FWIW, the query that determines if there already is a row in the DB for a specific session ID is executed on line 166 of Session_database_driver.php. I don't really want to do testing on the production environment, but I might put the production website in maintenance mode super late tonight and give it a shot.
I assume you are using your name-brand site for this test?
Is this occurring on any other of your live websites? I know your new hook has not been available until recently, but it might be worth a test if you have another site that could be updated. I know I'm not offering real solutions, but perhaps my questions may help... I get brain lockup sometimes, when I'm too tired to think straight<g>.
CI 3.1 Kubuntu 19.04 Apache 5.x Mysql 5.x PHP 5.x PHP 7.x
Remember: Obfuscation is a bad thing. Clarity is desirable over Brevity every time.
I own a sewing machine store, and the errors were coming from the store's production website. Since I implemented the new error reporting hook (a few days ago) I started getting emails associated with this error. So I started blacklisting the bots from the session, one by one. Today I thought I might try to track down what the error is, and I thought I had a good idea of what it might be, but now all the sudden I can't get the website to give me an error. You can imagine the frustration.
As a test, I fresh installed CodeIgniter 3.0.6 with Community Auth on an old domain of mine. No problems. Wen't to my store's website, played around with things, and the last thing I tried was renaming the session from ci_session to ciSess. Problem went away. I thought great, let me switch it back to verify that the problem comes back. Nope, still no problem. Seriously, I didn't do anything, and now I can't reproduce the problem. Error reporting hook: PHP Code: <?php |
Welcome Guest, Not a member yet? Register Sign In |