• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

With SVN 7388, click on attach and you get:

TWiki detected an error or attempted hack - please check your TWiki logs and webserver logs for more information.

Use of uninitialized value in substitution iterator

-- PTh

Doesn't happen if localisation is turned off. Stack trace:

Use of uninitialized value in substitution iterator at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/I18N.pm line 69.
        TWiki::UI::__ANON__('Use of uninitialized value in substitution iterator
                                at /home/vir...') called at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/I18N.pm line 69
        TWiki::I18N::Fallback::maketext('TWiki::I18N::Fallback=HASH(0x87efae8)',                                '*Help:* Please see <a target=\'TWikiVariables\' onclick="return ...') called at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/Templates.pm line 219
        TWiki::Templates::_expandMaketext('TWiki::Templates=HASH(0x86443fc)', undef) called at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/Templates                               .pm line 280
        TWiki::Templates::readTemplate('TWiki::Templates=HASH(0x86443fc)', 'attachnew', 'pattern') called at /home/virtual/site2/fst/home/develop/twikisvn/lib/T                               Wiki/UI/Upload.pm line 105
        TWiki::UI::Upload::attach('TWiki=HASH(0x80fbbf0)') called at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/UI.pm line 97
        TWiki::UI::__ANON__() called at /home/virtual/site2/fst/home/develop/twikisvn/lib/CPAN/lib///Error.pm line 387
        eval {...} called at /home/virtual/site2/fst/home/develop/twikisvn/lib/CPAN/lib///Error.pm line 379
        Error::subs::try('CODE(0x87b1f28)', 'HASH(0x88117cc)') called at /home/virtual/site2/fst/home/develop/twikisvn/lib/TWiki/UI.pm line 146
        TWiki::UI::run('CODE(0x81f4f50)') called
[Tue Nov  8 23:54:54 2005] [error] [client] File does not exist: /home/virtual/site2/fst/var/www/html/favicon.ico


I can hardly believe this is caused by the small template change I did in attach.pattern.tmpl. I also cannot verify it on my system.


Yes, it was caused exactly by that: you were wasking for a [_1] parameter that didn't exist.

Solved in r7403.


Did you fix the code to be more forgiving, or did you fix the missing parameter? Both should be done.

-- PTh

I did not change that line. But oh well... AC

Unitialized variable warnings are issued when the {WarningsAreErrors} configure item is set true. To be more forgiving, set it false. I prefer that as many people as possible keep it true so we pick up on, and fix, these sorts of problems. A missing [_1] is a bug, and needs to be seen so it can be fixed.


I've fixed the missing parameter.

Arthur, sorry for the tone. Maybe that error was introduced by me, I don't know.


This is a general architecure question. Showing a "TWiki detected an error or attempted hack" error for a TWiki internal bug is too harsh and intimidating for end users. A more user friendly approach is to render the page as good as posssible and notify the admin by whatever means. Hence my earlier assertion that "die" in a CGI program is bad.

-- PTh

Peter, that's how the thing works when {WarningsAreErrors} is off. Eventual missing parameters just become empty in the resulting string, and the admin do get notified about the Perl warning.]]

The intention is that we developers use {WarningsAreErrors} on so we can find those situations (possibly avoidable warning-situations) in development-time.


Internal errors are reported this way is to eliminate the exposure of internals to hackers. The approach has been consistently recommended by the security experts. It's also more friendly to an end user than the alternative.

It is impossible to make code bulletproof, and it is general industry practice to highlight errors so they get found and fixed as early as possible. That's why we have testcases, and why their failure is a fatal stop on the development.

Internal errors are a reality, and the strategy for dealing with them has to be realistic as well. Reporting the error is much better than silently ignoring it and making "best efforts" to render anyway, as the error may have silent and deadly effects. It may result in incorrect error presentation, or in a worse case in data corruption. Errors that are ignored are also ignored by developers, meaning they never get fixed.


Summary Attach gives attempted hack error
ReportedBy PeterThoeny
AppliesTo Engine

Priority Urgent
CurrentState No Action Required

Checkins 7403
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r14 - 2005-11-13 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback