API HTTP¶
Além da função de serviço web descrita em API de serviço web, o plugin expõe um conjunto de
endpoints HTTP próprios, fora do subsistema de web services do Moodle, usados pelo Painel AVA
para operações que essa função não cobre. Eles vivem em api/ (v1) e api/v2/ (v2, ainda
em desenvolvimento).
Mecanismo de despacho e autenticação¶
Cada versão tem um único ponto de entrada (api/index.php e api/v2/index.php) que:
Lê o primeiro parâmetro da query string (
$_SERVER["QUERY_STRING"]dividida por&) como nome do serviço — por isso as chamadas usam a forma?nome_do_servico&outro_param=valor(o nome do serviço não énome=valor, é apenas o primeiro token da query string, como emrequests.http).Verifica esse nome contra uma lista fixa (whitelist) de serviços permitidos.
Inclui o arquivo
{servico}.phpcorrespondente e instancia a classe{namespace}\{servico}_service, que estendetool_painelava\service(api/servicelib.php).Chama
service->call(), que primeiro executaauthenticate()e, se bem-sucedida,do_call()— cujo retorno é serializado como JSON.
// api/servicelib.php — autenticação usada por todos os serviços v1 e v2.
public function authenticate() {
$syncupautotoken = config('auth_token');
$headers = getallheaders();
$authenticationkey = array_key_exists('Authentication', $headers) ? "Authentication" : "authentication";
if (!array_key_exists($authenticationkey, $headers)) {
throw new \Exception("Bad Request - Authentication not informed", 400);
}
if ("Token $syncupautotoken" != $headers[$authenticationkey]) {
throw new \Exception("Unauthorized", 401);
}
}
Ou seja, toda chamada precisa do cabeçalho Authentication: Token <auth_token>, onde
<auth_token> é o valor configurado em Administração do site → Plugins → Ferramentas de
administração → Painel AVA (ver Instalação). Erros (autenticação, parâmetros ausentes,
exceções internas) são capturados por um manipulador global que responde em JSON no formato
{"error": {"message": ..., "code": ...}} com o código HTTP correspondente.
Warning
Este mecanismo não usa o sesskey/CSRF nem o controle de capacidades do Moodle — a única
barreira é o token compartilhado. NO_MOODLE_COOKIES é definido antes de carregar
config.php, então nenhuma sessão de navegador é considerada.
Endpoints v1 (api/)¶
Serviço |
Arquivo / status |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sem arquivo correspondente |
|
sem arquivo correspondente |
Danger
sync_up_enrolments e sync_down_grades constam na whitelist de
api/index.php, mas não existe api/sync_up_enrolments.php nem
api/sync_down_grades.php no repositório. Uma chamada a esses dois nomes de serviço passa
pela whitelist, falha no require_once do arquivo inexistente e resulta em erro fatal do
PHP (não em uma resposta JSON de erro controlada, já que isso ocorre fora do bloco
try/catch de classe). Trata-se de funcionalidade referenciada, mas nunca implementada.
get_diarios¶
O endpoint mais complexo do plugin: monta a “timeline” de cursos do usuário na visão do Painel
AVA, agrupada em abas dinâmicas conforme o campo personalizado sala_tipo de cada curso
(ex.: diarios, ou qualquer outro valor presente nesse campo — exceto autoinscricoes,
tratado como um alias de diarios), mais uma aba especial autoinscricoes com cursos em
“vitrine” disponíveis para autoinscrição — ver Dados e campos personalizados.
Parâmetro ( |
Padrão |
Descrição |
|---|---|---|
|
— |
Username Moodle do usuário alvo. Se não encontrado, o retorno traz listas vazias. |
|
|
Filtros aplicados apenas à aba |
|
|
Um de |
|
|
Repassado como ordenação SQL para |
|
|
Recebido, mas não utilizado no corpo do método |
|
|
Recebidos, mas não aplicados à consulta nem à resposta — não há paginação real implementada apesar de os parâmetros existirem. |
Retorna um objeto com semestres, disciplinas e cursos (listas de opções, extraídas
dos campos personalizados de todos os diários do usuário, para uso em filtros no Painel AVA),
mais uma chave por “aba” identificada (tipicamente diarios, e qualquer outro valor de
sala_tipo presente, incluindo autoinscricoes quando há cursos elegíveis).
get_progresso¶
Parâmetro |
Padrão |
Descrição |
|---|---|---|
|
— |
Username Moodle. Se não encontrado, retorna lista vazia. |
|
|
Lista de IDs de curso separados por vírgula; se omitido, considera todas as matrículas ativas do usuário. |
Retorna, para cada curso com conclusão de curso habilitada
(enablecompletion == COMPLETION_ENABLED), id, progress (inteiro arredondado, ou
null) e hasprogress (booleano). O tempo total de execução é registrado via
error_log() com o prefixo [PROFILER - TOTAL] — não removido de produção.
get_atualizacoes_counts¶
Recebe username e retorna a contagem de conversas não lidas
(core_message_external::get_unread_conversations_count) e notificações popup não lidas
(message_popup_external::get_unread_popup_notification_count) do usuário. Se o usuário não
existir, retorna um corpo com error preenchido, mas ainda assim com HTTP 200 (o código de
erro só aparece dentro do JSON, não no status HTTP).
get_course_info¶
Recebe courseid e (opcionalmente) username. Retorna id, fullname, shortname,
summary (formatado via format_text), is_enrolled (se username informado e
matriculado ativamente), a lista docentes (nome, foto e descrição de todo usuário com a
capacidade moodle/course:update no curso, ordenada alfabeticamente) e carga_horaria
(lida do campo personalizado de curso carga_horaria, tentando decvalue, depois
charvalue, depois intvalue).
set_favourite_course / set_visible_course¶
Ambos recebem username e courseid:
set_favourite_coursetambém recebefavourite(1/0/true/false); valida o formato dousername(regex^[a-z0-9._@+-]+$, máx. 100 caracteres), assume a identidade do usuário via\core\session\manager::set_user()e delega paracore_course_external::set_favourite_courses().set_visible_coursetambém recebevisible; exige que o usuário identificado porusernametenha a capacidademoodle/course:visibilityno contexto do curso (senão lança HTTP 403) e então atualizacourse.visiblediretamente via$DB->update_record().
set_user_preference¶
Recebe username, name e value (todos obrigatórios). Normaliza value para
'1'/'0' quando reconhecido como booleano, para inteiro quando numérico, ou mantém como
string, e grava via set_user_preference() (API nativa do Moodle).
sync_user_preference¶
Note
Diferente dos demais, este arquivo não define uma classe *_service — ele é um script
autocontido que faz o caminho inverso dos outros: em vez de o Painel AVA chamar o Moodle,
sync_user_preference.php é chamado (presumivelmente por uma ação do usuário no Moodle) e
ele mesmo faz uma requisição HTTP de saída para o Painel AVA
({painel_url}/api/v1/set_user_preference/), autenticando-se com o mesmo auth_token
como Bearer/Authorization: Token. Requer category, key e value via GET;
usa o usuário Moodle autenticado ($USER->username) como identificador.
enrol_course¶
Matricula username em courseid. Se o usuário não existir, ele é criado sob demanda
(“JIT provisioning”) com os dados opcionais firstname, lastname, email (padrão
{username}@sememail.ifrn.edu.br) e campus, usando auth =
get_config('local_suap', 'default_auth') (ou manual se local_suap não estiver
instalado) e aplicando default_user_preferences de local_suap, se configuradas. Em
seguida:
se já existir matrícula ativa, retorna
already_enrolledsem alterar nada;se existir matrícula suspensa, reativa-a (
status = 0) e retornareactivated;caso contrário, cria uma matrícula manual nova (
roleid = 5, papel student) e retornaenrolled.
Em qualquer caminho que resulte em matrícula ativa, chama
group_helper::ensure_user_in_profile_based_group() — ver Dados e campos personalizados.
suspend_enrol¶
Recebe username e courseid. Se não houver matrícula, retorna not_enrolled; se já
suspensa, retorna already_suspended; caso contrário, suspende (status = 1) via
$plugin->update_user_enrol() e retorna suspended. Diferente de uma remoção de matrícula,
os dados de progresso do aluno são preservados.
Endpoints v2 (api/v2/)¶
api/v2/index.php é um dispatcher independente, com sua própria whitelist
(get_notificacoes, patch_notificacao, get_conversas, patch_conversa,
get_salas, token_refresh, token_revoke) e o mesmo mecanismo de autenticação por
token (herdado de tool_painelava\service).
Warning
Todos os sete endpoints v2 existem como arquivo e respondem sem erro, mas todas as implementações atuais são placeholders — não consultam o banco de dados de forma significativa nem produzem dados reais:
Serviço |
Comportamento atual |
|---|---|
|
Sempre retorna |
|
Sempre retorna |
|
Busca o usuário por |
|
Sempre retorna |
|
Sempre retorna uma estrutura fixa com |
|
Sempre retorna |
|
Sempre retorna |
Nenhum desses efetivamente lê parâmetros de entrada além de, no máximo, username (em
get_notificacoes, sem uso no resultado). Trate a API v2 como uma interface ainda em
construção, não como uma integração funcional.
Exemplo de chamada¶
requests.http (raiz do repositório) documenta um exemplo real de chamada v1:
GET http://moodle/admin/tool/painelava/api/?get_diarios&username=admin&situacao=inprogress
Authentication: Token changeme