We maintain a lot of TYPO3 projects and in some of these we sometimes get strange log entries where controllers or actions of an extension are requested, which, for sure don't exist.
For example some log entries:
The controller "(SELECT (CASE WHEN (2302=2302) THEN 2302 ELSE 2302*(SELECT 2302 FROM INFORMATION_SCHEMA.CHARACTER_SETS) END))" is not allowed by plugin "List". Please check for TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php
The controller "Shop') AND 3375=(SELECT UPPER(XMLType(CHR(60)||CHR(58)||CHR(113)||CHR(112)||CHR(120)||CHR(118)||CHR(113)||(SELECT (CASE WHEN (3375=3375) THEN 1 ELSE 0 END) FROM DUAL)||CHR(113)||CHR(98)||CHR(118)||CHR(98)||CHR(113)||CHR(62))) FROM DUAL) AND ('CnON'='CnON" is not allowed by plugin "List". Please check for TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php
The action "listFilter UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL#" (controller "...") is not allowed by this plugin / module. Please check TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin() in your ext_localconf.php / TYPO3\CMS\Extbase\Utility\ExtensionUtility::configureModule() in your ext_tables.php
Are these requests from bots and can we prevent this somehow, or can we simply ignore the entries?
These are requests from bots that try to inject SQL into TYPO3. You can ignore them, as long as you are confident that your installation is up to date and your extensions are well maintained.
Related
How can I overwrite the default settings of the TYPO3 extension realurl with my own extension?
this dont work:
// RealUrl Config File
if (!isset($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile'])
|| empty(trim($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile']))
) {
$GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile'] = 'typo3conf/ext/xxx/Resources/Private/Hooks/realurl_conf.php';
}
How can I use this?
Probably the problem is that realurl is inialized and executed very early (it's the first process which needs to translate the speaking url to url parameter which decide which page and which plugin is rendered).
Your attempt to modify the assignment which is done normaly in typo3conf/LocalConfiguration.php could not be attached to that file as it is just an array, which gets written anew automatically every now and then.
You might add that to typo3conf/AdditionalConfiguration.php.
But why don't you request an admin to assign the path to the config-file in your extension in the realurl EM-config by hand?
I upgraded my tiki from 15.4 to 16.2. Everything runs fine. The problem is the site registration does not work. I have a tracker to extend my user information. In the tracker, I created a field called "Network" that allows the users to choose a group that them want to be in. Hence, they won't see each other content due to different group permission. This registration broke. The error message showed:
Cannot add nonexistent user xxx to group students
I found out the problem was that there is a change in trackerlib.php line 3671. Instead of returning "null", it now returns an empty array().
else {
return array();
}
In GroupSelector.php, line 124, the condition check
if (empty ($creators))) $creators=array($user);
This if will never be executed since the function now return an array not null. Hence causing the problem that no one can be registered if they choose a group in the registration form.
Propose solution, change the if condition in line 124 to:
if (empty($creators[0]))
My fix has now been improved by our colleague kroky6 (thanks!) and is now in the 16.x branch, so you can test it by using the 16.x nightly tarball from here tomorrow and will be in 16.3 (and 17.0 onwards) coming soon...
Did you check the actual 16.x version (dev branch) of this file (lib/core/Tracker/Field/GroupSelector.php) ?
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/branches/16.x/lib/core/Tracker/Field/GroupSelector.php
Chances are, this is fixed already. :)
Bernard
I am using extension advanced FE Editing in "typo3" ..
After installation , i can see active editing and deactivate editing ..
but when i try to edit from front-end ( with log in of admin )
i get error message ,
Oops, an error occurred!
Class TYPO3\CMS\Backend\Sprite\SpriteManager does not have a constructor, so you cannot pass any constructor arguments
i write in typoscript like this ,
<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/default/TypoScript/setup.ts">
page.config.admPanel = 1
or
i also tried this
<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/default/TypoScript/setup.ts">
config.admPanel = 1
help me , how can i solve this error ?
The Advanced Frontend Editing extension is not actively maintained at the moment and only compatible up to TYPO3 4.7. There are ongoing discussions about how to proceed with it:
http://forum.typo3.org/index.php/t/201671/
So currently you need to stick to the classic frontend editing in TYPO3 (sysext:feedit) or try out the frontend editing based on Aloha:
http://typo3.org/extensions/repository/view/aloha
In file: ext/quick/ext_tables_static+adt.sql
...
INSERT INTO `tx_quick_string` (`name`, `vlaue`) VALUES
('catalog', 'this is group one');
...
I want to change the value to 'this is group 1'. This is what I did:
a.changed it in this file:ext/quick/ext_tables_static+adt.sql
b.changed it in typo3/phpmyadmin->table tx_quick_string
It seems work. But I have some questions:
1.Does this file ext_tables_static+adt.sql only take effect when install/uninstall extension?
2.Is there anything else I need to do after I changed the value in ext_tables_static+adt.sql and typo3/phpmyadmin->table tx_quick_string? Do I need to update the extension in EM?
Yes, only when you install the extension.
No, if you already did the db update manually, there is nothing more to do.
If the extension you mentioned is not maintained by you, the files may get reverted during the next update of this extension, keep that in mind!
Apart from the things you asked I strongly advise you to NOT use the phpmyadmin extension of TYPO3. It has security problems on a kind of regular basis. So the better and more secure solution is to either use the db management tool your hosting company provides (they will keep it running and updated) or to put a separate tool somewhere else and secure it with a password (like htaccess restriction or something).
This is my 1st question on this forum... So, please, be indulgent !
I'm using TYPO3 4.7.11 (PHP 5.3.3) with extension direct_mail 3.1.1 for the intranet site of a non-profit firm.
My problem (maybe connected to Bug #51583 : http://forge.typo3.org/issues/51583) is that, after numerous tests and attempts, it seems impossible to have an updated version of a page saved as draft for newsletter in an automatic scheduler driven way : the same newsletter is produced with the same informations that were already there on the day it was first created and saved.
The specific page used for newsletter includes a content element 'Menu/Sitemap' with 'Recently updated pages' as 'Menu type'. It has been saved as 'draft (for recurring sendings)' in Direct Mail.
The scheduler contains these 2 tasks with recurring type :
- Direct Mail: Create Mail from Draft (direct_mail)
- Direct Mail: Mailing Queue (direct_mail)
Note : the manual way is fully functional and the newsletter produced is really updated. Same with option "Testmail - Simple" !
So, my problem seems to be linked to the automatic scheduled mailing ! It looks as if the newsletter draft has turned into a freezed snapshot of a specific moment and that Typo3 is unable to update/recalculate this page when invoked in scheduler mode.
On the web, I saw reported problems that could be related like "When mails get sent via the scheduler the same subject is used for all sendings ( https://review.typo3.org/21313 )" and "Adding hooks when sending direct mails via scheduler ( forge.typo3.org/issues/48994 )", but these issues seem to be fixed with direct_mail 3.1.1 version.
I made these observations and, in my opinion, there is some relevancy :
1.There is no domain proposed in the 'Domain of internal links' drop-down list in 'Set default values for mail content fetching options' in Direct Mailer, and yet I have a single record in sys_domain table with a domain name (with no protocol and no final slash). Is there a reason why this record is not considered good, or isn't it the right table ? (uid=3, pid, tstamp, crdate, cruser_id, hidden, sorting, prepend_params and forced=0, redirectHttpStatusCode=301, domain_name=site.subdomain.domain, redirectTo=)
2.In the Typo 3 Log, I get this systematic error message for user _cli_scheduler#LIVE :
Core: Error handler (BE): PHP Warning: Invalid argument supplied for
foreach() in
...typo3conf/ext/direct_mail/Classes/Scheduler/MailFromDraft.php line
125.
The concerned part of MailFromDraft.php is this function : initializeHookObjects
...
/*
* Initializes hook objects for this class
*
* #return void
*/
function initializeHookObjects() {
foreach ($GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] as $hookObj) {
$hookObjectInstance = t3lib_div::getUserObj($hookObj);
if (is_object($hookObjectInstance) && ($hookObjectInstance instanceof x_directmail_Scheduler_MailFromDraftHook)) {
$this->hookObjects[] = $hookObjectInstance;
}
}
}
...
I'm not sure of understanding very clearly the origin and the use of the hook Object... (in spite of this interesting article by Robert Lemke : typo3.org/documentation/article/how-to-use-existing-hooks-in-your-own-extension/ )
3.Nothing like the apparently requested GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['direct_mail']['mailFromDraft'] seems to exist in TYPO3_CONF_VARS (Global configuration).
Can anybody give me an advice or a clue about what's going on and why I can't get a weekly updated newsletter with the scheduler ? I feel a bit confused !
Thanks in advance for any suggestion or solution (if a miracle is possible).
Greetings.
P-H SILLIAU
I've read about this issue before, but couldn't remember where.
Googling "direct_mail draft (for recurring sendings)" helped.
Try this bug: http://forge.typo3.org/issues/4421
User Markus says:
Things work fine, when you set a domain-record in your system and
select it in the direct_mail settings!
If you don't have a domain-record and specify it in the direct_mail
setup you're able to send normal newsletters, but if you try the
draft-functionality it won't work because the getUrlBase function in
class.tx_directmail_static.php returns an unsuable URL to the System
so it can't use the fetchHTML($file) and quits - therefore not
replacing the old draft contents created when starting the first time.
I don't really get why this works the first time you set up the draft
though....
So setting up the domain-record is a work-around that works.
I hope it does!
Probably, you will find more related topics.
Else, workarounds would be
re-considering the task. As it's a NPO intranet, maybe requirements are not that required suddenly, if asked again :-)
setting up a custom notification tool that only does that precise job.
To put an end to this problem, after many attempts (and informations gleaned from the internet), here is the solution we finally used in our specific case to make the newsletter work :
1st. We created a record in table sys_domain. This was a recurrent instruction in the manual and the forums, and it was IMHO legitimate.
Important : note that the redirectTo field had to remain empty, due to global malfunction of the site if filled (whatever we put in it like /, /var/www/sitename, ...)
2nd. All images, CSS, JS included in template had to be hardcoded (i.e. http ://site/fileamin/images/xxx.png for instance). If we didn't do that, the result would have been an abort in the production of the newletter : Not Found... Maybe, by digging a bit deeper, should we be able to find a parameter we forgot or neglected in some way to solve this issue...
3rd. In the newsletter template TS setup, we added these 2 parameters :
mod.web_modules.dmail.use_domain=[uid of sys-domain]
config.absRefPrefix = / (in order to get rid of PHP DOCUMENT_ROOT (or TYPO3_DOCUMENT_ROOT ?) otherwise wrongly present in all generated links.)
The result is now a well dynamically-generated newsletter, the date is OK, all links are correct and realUrl-compliant (no ../index.php?id=nnn) .... and you know what ?... We're happy ! :-)
Hope it will help !
Many thanks to everybody who answered (Markus, Urs...) or even thought of a possible solution...
P-H Silliau