I moved my site again, to an even faster server than last time. Nice side benefit of working for an internet company.
A weird thing happened though, my google gadgets quit working when viewed on my iGoogle homepage. What was baffling me is that before making the site live I checked that both my cron job was working correctly to generate the updates, and that the generated files were happy and accessible. Example of happy and accessible file: http://www.vaughnsphotoart.com/googlegadgets/random-landscape-photo.html
The error was an odd one too, a 403 access forbidden. Yet I could view the files just fine, outside of the igoogle page, which meant some combination of Google's handling of the link and my new server made it barf. Google links directly to the file, but they append all kinds of parameters to the url:
http://www.vaughnsphotoart.com/googlegadgets/random-landscape-photo.html?lang=en&country=us&.lang=en&.country=us&synd=ig&mid=62&ifpctok=-7539280821549177493&exp_split_js=1&exp_rpc_js=1&exp_track_js=1&exp_ids=300403&parent=http://www.google.com&libs=hvXvLcAdreI/lib/liberror_tracker.js,V_hCLz15ZAw/lib/librpc.js,MgYjoHVg2rQ/lib/libcore.js&view=home
I separated out params one by one, and tracked it down to this one as the problem: parent=http://www.google.com
Spent about an hour trying to write an .htaccess RewriteRule that would remedy it, maybe encode the slashes and color or something, and then realized it was never even getting to my rule. Why? I went through server logs and eventually figured out that the new server is running the EasyApache ModSecurity module, and ModSecurity is taking offense to the "=http://www.google.com", thinking it is an injection attack.
So, I had to learn how to write rules for ModSecurity, and eventually wrote one to allow the google gadget requests to go through.
Ah, what fun.
A weird thing happened though, my google gadgets quit working when viewed on my iGoogle homepage. What was baffling me is that before making the site live I checked that both my cron job was working correctly to generate the updates, and that the generated files were happy and accessible. Example of happy and accessible file: http://www.vaughnsphotoart.com/googlegadgets/random-landscape-photo.html
The error was an odd one too, a 403 access forbidden. Yet I could view the files just fine, outside of the igoogle page, which meant some combination of Google's handling of the link and my new server made it barf. Google links directly to the file, but they append all kinds of parameters to the url:
http://www.vaughnsphotoart.com/googlegadgets/random-landscape-photo.html?lang=en&country=us&.lang=en&.country=us&synd=ig&mid=62&ifpctok=-7539280821549177493&exp_split_js=1&exp_rpc_js=1&exp_track_js=1&exp_ids=300403&parent=http://www.google.com&libs=hvXvLcAdreI/lib/liberror_tracker.js,V_hCLz15ZAw/lib/librpc.js,MgYjoHVg2rQ/lib/libcore.js&view=home
I separated out params one by one, and tracked it down to this one as the problem: parent=http://www.google.com
Spent about an hour trying to write an .htaccess RewriteRule that would remedy it, maybe encode the slashes and color or something, and then realized it was never even getting to my rule. Why? I went through server logs and eventually figured out that the new server is running the EasyApache ModSecurity module, and ModSecurity is taking offense to the "=http://www.google.com", thinking it is an injection attack.
So, I had to learn how to write rules for ModSecurity, and eventually wrote one to allow the google gadget requests to go through.
Ah, what fun.