I’ve implemented new neat feature (to store unique content only once in cache) to my perl based etl tool and suddenly it started to print sometimes ‘Wide character in subroutine entry‘ perl warning in sha1_hex call. As if this was not enough processed content after being stored in cache started to be utf-8 corrupted in comparition to the one stored in the cache.
It took few funny hours with of playing with perl, till I’ve found that sha1_hex function somehow destroyed parameter content but in such a beautiful way, that it was almost impossible to detect it. What the best is the cached content was output of LibXML toString() function, but the XML tree itself (or what) has been also corrupted. Well it must one of that ‘perl secrets’.
Afterwards Google given me some explanation of this activity – I’ve found similar problem reported for md5_sum function from digest::md5 package.
So finally to fix that problem, one must call encode_utf8() on sha1_hex parameter to let sha1_hex work on this copied content.
Hurray, after a longer period of no new posts, my blog comes back to life.
Because of migration to new hardware, different virtualization platform (Xen), replacing Debian with Gento and whole system philosophy upgrade I’ve had no spare time to write new posts (to be true, it was big problem for me to find some time to do all that things). Now I’m running new WordPress so I hope I will find some time to write about problems I’ve experienced when doing all that work I’ve mentioned above (and there were many).
I’ve also some plans to improve this site, but now I’m happy it works as good as before 
Just a quick post about a little (and nasty) bug I’ve found in Google Docs. I’ve already contacted Google 2 months ago (11 Februar), but they seem to have better work (counting money or smth. like that) and I didn’t received any response nor the bug has not been fixed.
Description:
Anyone with invite link to some specific document stored in Google Docs, can view this document regardless of sharing properties defined. This includes also guest visitors of the document, and that means no signing-in to Google Docs service is required to access such a link and view private document. Well maybe this is some kind of ultra easy accessibility feature, but for me it looks like a bug
Example:
https://docs.google.com/Doc?docid=0AYYA7ZD-UOAFZHY1bXFucV8zM2RjM3NtNmNu&hl=en
This document is private, shared only with one another account and i presume you can not view it, but if you use this link
https://docs.google.com/Doc?docid=0AYYA7ZD-UOAFZHY1bXFucV8zM2RjM3NtNmNu&hl=en&invite=CI-f3KoG
you can see it’s content. Not very optimal.
How-to reproduce:
- create document
- share it with someone
- use the invite link to feel like a hacker and view your own private document without being signed-in,
How-to abuse:
Well not so easily, you must get the invite link somehow. But, I think it is not so hard as it seems. The invite link works even after the original user has been disallowed to view the document, so something as revoking access to a Google Document to someone that already had access to is is only a pure dream.
Have a nice day
Released solr_pager 0.2.2. This release fixes little bug that prevented solr_pager to work in some configurations (ie. with standard search handler). Well, Solr documentation did not mentioned that it can pass empty (null) result set to my component.
Also added some sanity checks to prevent similar situation again.
New version can be found on http://devel.dob.sk/solr_pager, enjoy.
Released solr_pager 0.2.1, an feature update with improved first/last page navigation. Now they appear in result only when first/last page is not visible in generated paging list.
This version can be found on http://devel.dob.sk/solr_pager, for more informations about how it works see this post.