Recursoseduc não mostra dados
Verificar no ficheiro recursos.php se as tags do PHP estão declaradas ou se usam short tags.
Ativar as short_tags no php.ini NÃO É HIPÓTESE! 🙂
Verificar no ficheiro recursos.php se as tags do PHP estão declaradas ou se usam short tags.
Ativar as short_tags no php.ini NÃO É HIPÓTESE! 🙂
Em algumas categorias e disciplinas do Moodle apareciam DIVs com publicidade no cabeçalho e no rodapé… A publicidade estava na descrição das próprias categorias e disciplinas e foi adicionada involuntariamente por um dos admins/responsáveis porque tinha o browser infectado…
Para verificar quais as tabelas do Moodle que têm scripts, faz-se uma pesquisa na base de dados…
Se aparecer algum resultado diferente de 0, pode ser ali que estão os scripts.
Quando tiver algum tempo tenho que estudar bem as funcionalidades destes plugins.
GISMO
GISMO, a graphical interactive student monitoring and tracking system that extracts tracking data from an online course maintained with Moodle, and generates graphical representations that can be explored by course instructors.
https://moodle.org/plugins/view.php?plugin=block_gismo
GMoodle
GMoodle é um sistema de gerenciamento da Plataforma Moodle. Atende a necessidade de integração de vários ambientes Moodle. Oferece agilidade no gerenciamento e diversos tipos de relatórios não disponíveis no Moodle.
É uma ferramenta de gestão de website Moodle projetado para instituições que precisam extrair relatórios mais gerenciais, o que o Moodle não oferece. Além disso, permite integrar diversos ambientes Moodle, de diferentes versões, distribuídos em vários servidores. É uma ferramenta projetada para ser um armazém de dados do Moodle destinado para emissão de relatórios gerenciais.
http://www.badiu.net/nportal/index.php?option=com_content&view=article&id=6
Code:
#Joomla com_jce exploit SecRule HTTP_User-Agent "BOT for JCE" "deny,status:500,id:5000218,msg:'Joomla com_jce code exec'" #Joomla com_jce exploit SecRule REQUEST_URI "/images/stories/.+\.php" "deny,status:500,id:5000219,msg:'Joomla com_jce code exec'"
The first blocks the user agent. That exploit puts PHP files into site.com/images/stories/something.php if it is successful, so the 2nd rule blocks access to those in case they change user agent.
Even with the .htaccess or this first rule, you should still use the 2nd rule. Changing user agents is very simple.
Outra sugestão:
https://github.com/bluedragonz/bad-bot-blocker
smtphosts: smtp.gmail.com:465
smtpuser: [email protected]
smtppass: *******
supportemail: [email protected]
Editar o ficheiro /lib/phpmailer/class.smtp.php na linha 83:
$host = 'ssl://' . $host;
e alterar a porta na variável $SMTP_PORT para 465:
var $SMTP_PORT = 465;
Editar o ficheiro /lib/phpmailer/class.phpmailer.php e alterar a porta na variável $Port para 465:
var $Port = 465;
Para desligar double authentication no Gmail ver aqui: https://docs.moodle.org/30/en/Email_setup_gmail
O Administrador desativou o método de autenticação por email e os utilizadores não conseguem fazer login.
É necessário editar manualmente a tabela config na base de dados e incluir “email” na linha com o name “auth”.
Colocar todas as pastas com permissão user:apache
chown -Rf user:apache public_html
Modificar as pastas para rwxr-xr-x:
find . -type d -exec chmod 755 {} \;
Modificar os ficheiros para rw-r–r–:
find . -type f -exec chmod 644 {} \;
Definir a permissão apache:apache para que algumas pastas possam ser escritas
chown apache.apache images/ chown apache.apache components/ chown apache.apache modules/ chown apache.apache plugins/ chown apache.apache language/ chown apache.apache templates/ chown -Rf apache.apache cache/ chown -Rf apache.apache logs/ chown -Rf apache.apache tmp/ chown apache.apache administrator/components/ chown apache.apache administrator/modules/ chown apache.apache administrator/language/ chown apache.apache administrator/templates/ chown apache.apache administrator/backups/ chown apache.apache administrator/cache/ chown apache.apache administrator/language/en-GB/ chown apache.apache administrator/language/pt-PT/ chown -Rf apache.apache images chown apache.apache images/banners/ chown apache.apache images/stories/ chown apache.apache language/en-GB/ chown apache.apache language/pdf_fonts/ chown apache.apache language/pt-PT/ chown apache.apache media/ chown apache.apache plugins/content/ chown apache.apache plugins/editors/ chown apache.apache plugins/editors-xtd/ chown apache.apache plugins/search/ chown apache.apache plugins/system/ chown apache.apache plugins/user/ chown apache.apache plugins/xmlrpc/
~
Listar todos os ficheiros index.php para descobrir os modificados ou criados…
find . -name "index.php" -exec ls -alh {} \;
Listar todos os ficheiros *.php com permissões apache.apache modificados ou criados…
find . -name "*.php" -user "apache" -group "apache" -exec ls -alh {} \;
Listar todos os ficheiros do user/grupo apache com exatamente 82kb
find . -name "*.php" -user "apache" -group "apache" -size 82k -exec ls -alh {} \;
Listar todos os ficheiros modificados no dia 9 de Novembro
ls -ahlR | grep 'Nov 9'
Listar todos os ficheiros modificados no dia 20 de janeiro de 2013
tree -ifpugDs $PWD | grep "Jan 20 2013"
Aqui fica a solução… o ponto 1 já eu tinha resolvido, faltava-me o 2.
I just ran into this same problem. For me it was the Apache module mod_security that was preventing the uploads. Drupal has some issues uploading files and images when running Apache’s mod_security using the default configuration settings. Here’s what I did to identify the problem and get it working.
Besides that javascript error, there should be an error in the apache error log that you can check.
Here’s the first error I was getting in the apache error log.
ModSecurity: Request body (Content-Length) is larger than the configured limit (131072)
The configured limit is 131072 BYTES! That’s only 128 kB!!
Edit /etc/apache2/conf.d/modsecurity.conf and set SecRequestBodyLimit to a larger size than the default of 128 KB and then reboot apache. I set mine to match my max_upload setting from my php.ini. Remember it has to be in bytes!
More Info about SecRequestBodyLimit
Description: Configures the maximum request body size ModSecurity will accept for buffering.
Syntax: SecRequestBodyLimit NUMBER_IN_BYTES
Example Usage: SecRequestBodyLimit 134217728
Processing Phase: N/A
Scope: Any
Dependencies/Notes: 131072 KB (134217728 bytes) is the default setting. Anything over this limit will be rejected with status code 413 Request Entity Too Large. There is a hard limit of 1 GB.
After I fixed that error I was able to upload files without a problem and things were running smooth…until I tried uploading a certain video. All my other videos uploaded fine except this one. I checked the Apache error log and saw:
ModSecurity: Warning. Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [file "/etc/apache2/conf.d/modsecurity.conf"] [line "60"] [msg "Multipart parser detected a possible unmatched boundary."]
After digging around on teh internets I found the rule referenced in the error above will sometimes return false positives, which will then deny the request. To fix that just remove the “deny” from the rule so that it will simply log when these events occur.
Edit /etc/apache2/conf.d/modsecurity.conf and update the rule for MULTIPART_UNMATCHED_BOUNDARY, setting it to log only.
OLD
# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
NEW (removed ‘deny’ from line 3)
# Did we see anything that might be a boundary?
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,msg:'Multipart parser detected a possible unmatched boundary.'"
Existem duas possibilidades para este erro ocorrer.
1. Nos cargos globais do Moodle as permissões estão modificadas ou não têm valores os valores por defeito.
2. Na tabela de contextos (mdl_context) a path está corrompida e os contextos estão trocados. Por exemplo, um módulo pode ter na path contextos de outras categorias ou outras disciplinas. Neste caso é necessário forçar a reconstrução da tabela de contextos.
Ver aqui como se faz: http://docs.moodle.org/19/en/How_to_rebuild_context_paths
O ficheiro config.php tinha um espaço em branco depois do ?> …