Ask for Help
*Is sunspot vulnerable to a ruby injection attack?
Sunspot requests ruby as an output format from solr, and evals the response. One project is seeing invalid unicode being passed to solr and coming back in the response, causing the eval error on the invalid characters. The consensus was that it probably wasn’t exploitable, but is unfortunate.
- Is there a way to put Jasmine in the test group without it causing errors on production?
This has gotten better in rails 3 but the fix has caused problems in rails 2 apps. For now you can install in every group or catch the exception when it tries to load it in production.
Interesting Things
- You can pass an array as the value of the :join parameter in ActiveRecord finders. This lets your write clearer code instead of having one long string with multiple joins.
I forked RSolr at 0.12.1 (the version used by stable Sunspot) and switched it to use the [JSON writer instead of Ruby](https://github.com/jasoncodes/rsolr/compare/4b96406…8be2404).
The reason for this was that I was getting “stack level too deep” when parsing large facet responses (> 64k rows, > 700 KB) which I use in a few batch operations. I didn’t run any benchmarks but I’d be surprised if this was significantly slower.
If you’re concerned about possible exploits you may want to try JSON as well.
April 13, 2011 at 8:17 pm
Thanks for the heads up on the Sunspot and Solr unicode issue. Pull requests are welcome, even if just a breaking spec. Or perhaps some sanitization before sending garbage data over to Solr.
The next round of Sunspot updates (hopefully soon, with Solr 3.1 recently released) should probably include a newer version of RSolr. I concur with Jason that switching to JSON is probably a good idea, too.
I’ll look into it.
—Nick
April 14, 2011 at 2:36 pm