Hi! My little application stand whole night and when on morning user made first request, app did not connect properly to Database. Error was like: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''utf8&am' at line 1 at /usr/local/share/perl/5.12.4/Dancer/Plugin/Database.pm line 198. /usr/local/share/perl/5.12.4/Dancer/Plugin/Database.pm around line 198 195 return; 196 } elsif (exists $settings->{on_connect_do}) { 197 for (@{ $settings->{on_connect_do} }) { 198 $dbh->do($_) or Dancer::Logger::error( 199 "Failed to perform on-connect command $_" 200 ); 201 } As i use also Plugin::EscapeHTML with automatic_escaping: 1, it seems that there is some problem with 2 of them together. At least there is made some weird escaping. Or? After restarting app, connenction to DB was alright. Main problem: how to avoid reconnecting failure? -- Wbr, Kõike hääd, Gunnar
On Thu, 12 Apr 2012 10:53:00 +0300 WK <wanradt@gmail.com> wrote:
Hi!
My little application stand whole night and when on morning user made first request, app did not connect properly to Database. Error was like:
DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '&amp;amp;amp;amp;amp;amp;amp;#39;utf8&amp;amp;amp;amp;amp;amp;am' at line 1 at /usr/local/share/perl/5.12.4/Dancer/Plugin/Database.pm line 198. /usr/local/share/perl/5.12.4/Dancer/Plugin/Database.pm around line 198 195 return; 196 } elsif (exists $settings->{on_connect_do}) { 197 for (@{ $settings->{on_connect_do} }) { 198 $dbh->do($_) or Dancer::Logger::error( 199 "Failed to perform on-connect command $_" 200 ); 201 }
Uh-oh - that's probably not good :) Do you have any on_connect_do settings defined in your app's config?
As i use also Plugin::EscapeHTML with automatic_escaping: 1, it seems that there is some problem with 2 of them together. At least there is made some weird escaping. Or?
That would seem to be the likely culprit, but at a quick glance, I don't see why that should be happening. D::P::EscapeHTML's automatic escaping stuff is in a before_template_render hook, and steps through the template params passed to it. Ah, wait. I think that's it - Dancer::Template::Abstract shoves the config information into the template tokens hashref: 148 $tokens->{settings} = Dancer::Config->settings; However, as Dancer::Config->settings returns us the actual hashref, we're storing a reference; D::P::EscapeHTML, if automatic_esaping is enabled, will follow that reference, trampling all over the values of the settings. That, needless to say, is Not Good, and is the cause of the problem. I think the proper fix is for me to change Dancer::Template::Abstract to copy the settings rather than storing a reference - e.g.: $tokens->{settings} = Clone::clone(Dancer::Config->settings); In the meantime, I'll also release a new version of D::P::EscapeHTML which will skip a template tokens key named "settings". Thanks for spotting & reporting this one :) Cheers Dave P -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On Thu, 12 Apr 2012 10:41:05 +0100 David Precious <davidp@preshweb.co.uk> wrote:
However, as Dancer::Config->settings returns us the actual hashref, we're storing a reference; D::P::EscapeHTML, if automatic_esaping is enabled, will follow that reference, trampling all over the values of the settings.
That, needless to say, is Not Good, and is the cause of the problem.
I think the proper fix is for me to change Dancer::Template::Abstract to copy the settings rather than storing a reference - e.g.:
$tokens->{settings} = Clone::clone(Dancer::Config->settings);
I've implemented that in a pull request: https://github.com/sukria/Dancer/pull/775 Please feel free to test that this fixes the issue for you (although I realise as the problem only manifested once the existing connection went away, it'll be somewhat tricky to reproduce, unless you can cause the database connection to drop via whatever means you choose). I've tested the fix with a simple test case which demonstrated the previously described problem, and verified that the changes in that PR do indeed fix it. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
Hi, I think there may be some other cases where we would hit this issue : What if the user has a global data structure, and passes it to the template in the tokens. It'll be passed as reference, and we'll be in the same issue, the Escape plugin will change the original data. Consider this pseudo example : my $global_hash = { foo => "&bar" } ; get 'some/route' => sub { template ( { global_hash => $global_hash } ) }; I know it's bad design to use a global variable like that, but you get the idea :) So, instead of cloning only the things Dancer purposely adds to the tokens, meybe either : - Dancer should clone the whole token hash (bad idea in my opinion, you want to be able to pass a dbh or a coderef) - Dancer escape plugin should take care of cloning the things he's changing - Or at least we should document that in Dancer, and in the excape plugin Any thought ? Or am I too picky ? :) On 12 April 2012 12:20, David Precious <davidp@preshweb.co.uk> wrote:
On Thu, 12 Apr 2012 10:41:05 +0100 David Precious <davidp@preshweb.co.uk> wrote:
However, as Dancer::Config->settings returns us the actual hashref, we're storing a reference; D::P::EscapeHTML, if automatic_esaping is enabled, will follow that reference, trampling all over the values of the settings.
That, needless to say, is Not Good, and is the cause of the problem.
I think the proper fix is for me to change Dancer::Template::Abstract to copy the settings rather than storing a reference - e.g.:
$tokens->{settings} = Clone::clone(Dancer::Config->settings);
I've implemented that in a pull request:
https://github.com/sukria/Dancer/pull/775
Please feel free to test that this fixes the issue for you (although I realise as the problem only manifested once the existing connection went away, it'll be somewhat tricky to reproduce, unless you can cause the database connection to drop via whatever means you choose).
I've tested the fix with a simple test case which demonstrated the previously described problem, and verified that the changes in that PR do indeed fix it.
-- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
2012/4/12 David Precious <davidp@preshweb.co.uk>:
Do you have any on_connect_do settings defined in your app's config?
Yes, i do: on_connect_do: ["SET NAMES 'utf8'", "SET CHARACTER SET 'utf8'" ] But you figured already out, of course.
Thanks for spotting & reporting this one :)
Your prompt reaction was awesome! As i had problem with reproducing situtation i thought how to test it. Seems you find solution here too? -- Wbr, Kõike hääd, Gunnar
On Fri, 13 Apr 2012 00:38:22 +0300 WK <wanradt@gmail.com> wrote:
As i had problem with reproducing situtation i thought how to test it. Seems you find solution here too?
What I did was scaffold a test app which loads D::P::EscapeHTML, and enables automatic_escaping, and includes some HTML in the config - for example, a config.yml like: plugins: EscapeHTML: automatic_escaping: 1 some_html: "Here's some <HTML> & stuff" Then, in the app, I created a route which displayed the current settings: get '/settings' => sub { "<pre>" . to_json( Dancer::Config->settings ) . "</pre>"; }; I hit that route first, and observed that the "some_html" config setting was not escaped. I then hit the app's default home page (which uses a template), then viewed /settings again. Before the fix, when I hit /settings after having had a template rendered, the "some_html" config setting had been escaped; after the fix, it was left alone. -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
participants (3)
-
damien krotkine -
David Precious -
WK