Codigo de validação de documentos

espsc_tecnologia · July 7, 2026, 6:17pm

Gostaria de saber se o sistema gibbon existe a possibilidade de gerar código de validação de documentos, ou alguma API para integra e fazer essa verificação ?

Xavier_Bit · July 14, 2026, 9:17pm

Olá!
Eu não acredito que tem algo pronto, especialmente fora das EUA ou Hong Kong a onde Gibbon está domiciliado.
Mas me deixe perguntar, qual sistema você gostaria de usar? Quando tem uma API uma integração deveria ser possivel como Gibbon é Open Source e você tem como modificar tudo.

espsc_tecnologia · July 15, 2026, 8:14pm

Eu gostaria de que os documentos feitos no modulo FReports tivesse esse tipo de validação e uma pagina aberta no sistema que o aluno verificasse a validação do documento.. ou uma forma outra forma de implementar isso ..

tiekubd · July 15, 2026, 10:19pm

Hi! Thanks for the example — that’s very helpful. I see you’re referencing the SEI verification pattern (verifier code + CRC + CAPTCHA). A few specific questions to nail down the design:

Should the verifier code be sequential per report (like SEI’s), or unique/random per student+report combination?
Should we include a CRC or similar checksum as a second field, so codes can’t be brute-forced/guessed in sequence like SEI does?
Should the public verification page require a CAPTCHA, given SEI includes one?
On successful verification, what should the page display — just “valid, issued on [date],” or also student name, report title, school year?
Should the QR code link directly to a pre-filled verification page, or just to the general verification page where the codes still need to be typed in manually?

espsc_tecnologia · July 20, 2026, 4:45pm

Sim. Se o objetivo é criar um Validador Público de Documentos para o SIGAS/Gibbon, o ideal é seguir o padrão utilizado por órgãos públicos brasileiros (SEI, e-CAC, tribunais, universidades federais, etc.), adaptando-o ao ambiente acadêmico.

Eu responderia às perguntas da seguinte forma:

1. O código de verificação deve ser sequencial ou aleatório?

Resposta: Nem totalmente sequencial, nem completamente aleatório.

O recomendado é utilizar um identificador único (UUID ou token criptograficamente seguro) para cada documento emitido.

Exemplo:

Código Verificador:
0004317

ou

A9F3-72D1-5E8B

O importante é que cada emissão gere um código exclusivo, mesmo que o aluno emita o mesmo relatório novamente.

Na tabela do banco:

documentValidator

id
validationCode
crc
personID
reportID
schoolYearID
created
hash
status

2. Deve existir um CRC?

Sim.

Essa é exatamente a abordagem utilizada pelo SEI.

Exemplo:

Código Verificador:
0003431

CRC
6C236426

O CRC não precisa ser literalmente um CRC32.

Pode ser:

CRC32

ou

SHA-256 truncado

Exemplo:

hash_hmac(
    'sha256',
    validationCode,
    SECRET_KEY
)

Guardar:

validationCode

0003431

crc

6C236426

Assim fica impossível alguém gerar códigos válidos apenas tentando números sequenciais.

3. Deve existir CAPTCHA?

Sim, para consulta pública.

É exatamente o que fazem:

SEI
TRF
TJ
Receita Federal
INEP

Motivos:

evita robôs

evita enumeração de documentos

evita ataques por força bruta

Mesmo um CAPTCHA simples já resolve.

Pode usar:

Google reCAPTCHA
Cloudflare Turnstile (recomendado)
CAPTCHA próprio do Gibbon

4. O que mostrar após validar?

Nunca mostrar o documento inteiro.

Mostrar apenas os metadados.

Exemplo:

Documento válido

Documento autêntico

Emitido por:

Escola de Saúde Pública de Santa Catarina

Tipo:

Histórico Escolar

Aluno:

Maria da Silva

CPF:

.123.

Curso:

Especialização em Saúde Pública

Ano Letivo:

2026

Emitido em:

15/07/2026 14:23

Status:

Válido

Código:

0003431

CRC:

6C236426

Se desejar, disponibilize também um botão:

Visualizar PDF Original

apenas se o documento puder ser público.

Caso contrário:

Documento validado.

5. O QR Code deve abrir o quê?

O ideal é exatamente como fazem os órgãos públicos.

O QR já contém o código.

Exemplo:

https://sigas.espsc.sc.gov.br/validate?code=0003431

A página abre com:

Código Verificador

0003431

já preenchido.

O usuário apenas informa:

CRC

6C236426

e resolve o CAPTCHA.

Isso impede consultas automáticas.

Fluxo recomendado

PDF

↓

QR Code

↓

Página Pública

↓

Código já preenchido

↓

Usuário informa CRC

↓

CAPTCHA

↓

Pesquisar

↓

Documento encontrado

↓

Mostra os metadados

↓

Documento válido

Modelo da página pública

--------------------------------------------
        Conferência de Autenticidade
--------------------------------------------

Código Verificador

[0003431            ]

Código CRC

[6C236426           ]

CAPTCHA

[  2011  ]

[________]

           [ Validar Documento ]

--------------------------------------------

Após validar:

✔ Documento Autêntico

Instituição:
Escola de Saúde Pública de Santa Catarina

Documento:
Certificado

Aluno:
Maria da Silva

Curso:
Especialização em Saúde Pública

Data da emissão:
15/07/2026

Status:
VÁLIDO

Código:
0003431

CRC:
6C236426

Estrutura sugerida da URL

https://sigas.espsc.sc.gov.br/documento/validar

ou

https://sigas.espsc.sc.gov.br/validacao

O QR Code pode apontar para:

https://sigas.espsc.sc.gov.br/validacao?c=0003431

Assim, apenas o campo Código Verificador fica pré-preenchido. O usuário informa o CRC e resolve o CAPTCHA, seguindo um padrão muito próximo ao adotado pelo SEI, universidades federais e demais órgãos públicos brasileiros.

Essa arquitetura oferece um bom equilíbrio entre facilidade de uso, segurança contra tentativas de enumeração e conformidade com as práticas amplamente adotadas na administração pública brasileira.

Olá em resumo,

Obrigado pelas perguntas e pelas sugestões. Nossa intenção é que o módulo de validação siga um padrão semelhante ao utilizado pelos órgãos da Administração Pública Federal, como o SEI, proporcionando segurança, confiabilidade e facilidade de uso.

Com relação aos pontos levantados:

Código de Verificação: deverá ser único para cada documento emitido, e não apenas para o aluno ou para o relatório. Dessa forma, cada nova emissão gera um novo código de validação, permitindo rastreabilidade e controle de versões.
CRC (ou código de integridade): sim, gostaríamos de adotar um segundo código de validação (CRC ou checksum), semelhante ao utilizado pelo SEI. Esse código servirá como mecanismo adicional de segurança, dificultando tentativas de descoberta dos documentos por meio de códigos sequenciais.
CAPTCHA: a página pública de validação deverá utilizar um CAPTCHA (ou solução equivalente, como Google reCAPTCHA ou Cloudflare Turnstile), evitando consultas automatizadas e tentativas de força bruta.
Informações exibidas após a validação: após uma validação bem-sucedida, a página deverá apresentar os principais metadados do documento, tais como:
- Situação da validação (Documento válido/inválido);
- Nome da instituição emissora;
- Nome do aluno;
- Tipo do documento (certificado, histórico, declaração, relatório etc.);
- Curso;
- Ano letivo;
- Data e hora de emissão.
A disponibilização do PDF original poderá ser avaliada posteriormente, de acordo com as regras de acesso definidas pela instituição.
QR Code: o QR Code deverá direcionar diretamente para a página pública de validação, com o Código Verificador já preenchido. O usuário informará apenas o CRC e resolverá o CAPTCHA para concluir a consulta, seguindo o modelo adotado pelo SEI e por diversas universidades e órgãos públicos brasileiros.

A expectativa é que o módulo ofereça uma experiência semelhante à dos sistemas oficiais de validação documental utilizados no Brasil, garantindo autenticidade, segurança e facilidade na conferência dos documentos emitidos pelo SIGAS.

Obrigado e fico à disposição para quaisquer esclarecimentos.

Atenciosamente,

ESPSC – Escola de Saúde Pública de Santa Catarina

tiekubd · July 22, 2026, 12:59am

Hi!
Quick update: I managed to put together a working prototype of the validation system we discussed, following the SEI pattern (verifier code + CRC + QR code + public lookup page with CAPTCHA). Tested it end-to-end and it’s working well — here’s a sample screenshot (fictional data). I have a few more technical questions to better understand what you need before moving forward. You can send me an email so we can continue this conversation with more detail?
tieku@ highpointedu. com

Cheers, Tieku

espsc_tecnologia · July 23, 2026, 5:29pm

Prefeito seria isso sim..

Olá, Tieku,

Obrigado pela atualização e por compartilhar o protótipo. Este é exatamente o tipo de sistema de validação de que preciso, especialmente a combinação do código de verificação, CRC, QR Code, página de consulta pública e CAPTCHA.

Tenho uma pergunta importante sobre a integração com o nosso sistema: Todos os relatórios gerados através do módulo modules/Reports receberão automaticamente este sistema de validação?

Para garantir que a rastreabilidade e a autenticidade por meio do código de verificação, CRC e QR Code estejam presentes em toda a documentação oficial da instituição, a integração do módulo de relatórios pode abranger diversos documentos escolares e acadêmicos.

Abaixo estão alguns exemplos fundamentais de documentos onde esse sistema de validação automática deve ser aplicado:

1. Documentos de Conclusão e Histórico

Histórico Escolar: O documento mais crítico, que acompanha o percurso do aluno e exige alta segurança contra falsificações de notas e cargas horárias.
Certificados e Diplomas: Comprovação formal de conclusão de cursos, formações ou capacitações.
Declaração de Conclusão de Curso: Emitida frequentemente antes da expedição do diploma oficial.

2. Documentos de Matrícula e Frequência

Atestado de Matrícula: Confirma que o aluno está regularmente matriculado na instituição em determinado período letivo.
Declaração de Frequência: Utilizada por estudantes para comprovar presença em aulas, estágios ou atividades obrigatórias.
Boletim Escolar: Relatório periódico de notas e desempenho acadêmico por trimestre/semestre.

3. Documentos Administrativos e Legais

Declaração de Regularidade / Vínculo: Comprova o vínculo ativo do estudante ou servidor com a instituição.
Ficha de Matrícula: O resumo dos dados cadastrais e disciplinas escolhidas no ato da renovação ou ingresso.
Planos de Ensino / Ementas: Relatórios detalhados dos conteúdos programáticos ministrados nas disciplinas (muito úteis para processos de aproveitamento de estudos em outras instituições).

Em outras palavras, meu objetivo é que cada relatório gerado pelo sistema seja registrado no banco de dados de validação e receba seu próprio código de verificação, CRC e QR Code. O QR Code direcionaria o usuário para uma página de validação pública onde a autenticidade do relatório pode ser verificada.

Você poderia explicar como essa integração funcionaria tecnicamente? Por exemplo:

Como a validação seria gerada quando um relatório é criado?
A validação ocorreria automaticamente para cada relatório gerado em modules/Reports?
Como os dados do relatório seriam registrados no banco de dados de validação?
O sistema seria capaz de validar o relatório usando o código de verificação, CRC ou QR Code?
Como a página de consulta pública estaria conectada aos relatórios gerados pelo sistema?

Esta é exatamente a funcionalidade que preciso, por isso gostaria de entender o processo de integração e como podemos garantir que todos os relatórios gerados pelo módulo modules/Reports sejam validados automaticamente.

Obrigado novamente pelo seu trabalho e pelo protótipo.

Atenciosamente,

Elaine

tiekubd · July 23, 2026, 10:10pm

Boa tarde, Elaine!

Obrigado por detalhar os tipos de documento — isso ajuda bastante a entender o escopo completo do que vocês precisam.

Vou responder suas perguntas técnicas:

Como a validação é gerada quando um relatório é criado?
O sistema se integra à arquitetura de extensão já existente no módulo Reports do Gibbon (o mesmo mecanismo usado para outros componentes personalizáveis de relatório). No momento em que um relatório é gerado, um código de verificação único e um código CRC (gerado criptograficamente, com uma chave secreta própria da instituição) são criados automaticamente e incluídos no rodapé do PDF, junto com o QR Code.

Isso ocorre automaticamente para todo relatório gerado em modules/Reports?
Sim — mas com uma ressalva importante: a validação precisa ser adicionada uma única vez a cada modelo/template de relatório, através do Template Builder do Gibbon. Depois desse passo inicial, toda vez que aquele modelo for usado para gerar um relatório, a validação acontece automaticamente, sem nenhuma ação manual adicional.

Um detalhe relevante que já resolvemos: o sistema distingue entre relatórios gerados como Rascunho e como Final — apenas relatórios finais recebem um código de validação real. Rascunhos não geram registros permanentes no banco de validação.

Como os dados são registrados no banco de dados de validação?
Cada relatório finalizado gera um registro em uma tabela dedicada, vinculado ao aluno, ao tipo de documento e ao ano letivo — sem alterar nenhuma tabela do núcleo do Gibbon.

O sistema valida usando código, CRC ou QR Code?
Os três trabalham juntos, seguindo o padrão do SEI que você descreveu originalmente: o QR Code direciona para a página pública com o código verificador já preenchido, e a pessoa digita o CRC manualmente. Essa combinação de dois fatores impede que alguém descubra códigos válidos por tentativa e erro.

Como a página pública se conecta aos relatórios gerados?
É uma página sem necessidade de login, protegida por CAPTCHA, que consulta a tabela de validação diretamente. Ela nunca mostra o PDF original — apenas os metadados do documento.

Já tenho isso funcionando de ponta a ponta em uma instância real do Gibbon, incluindo o acesso público sem login.

Sobre a lista de documentos que você compartilhou (Histórico Escolar, Certificados, Atestado de Matrícula, Boletim, Planos de Ensino, etc.) — tenho uma pergunta importante para entender o escopo completo: esses documentos já são gerados hoje através do módulo Reports do Gibbon (ou seja, já existem templates prontos para cada um), ou alguns/todos ainda precisariam ser construídos do zero? Isso muda bastante o escopo técnico, já que o mecanismo de validação em si é reutilizável entre todos os tipos de documento, mas cada template de relatório (layout, dados específicos) é um trabalho à parte da validação.

Fico à disposição para continuar esclarecendo qualquer dúvida técnica.

Atenciosamente,
Tieku

tiekubd · July 23, 2026, 10:38pm

Good afternoon, Elaine!

Thank you for detailing the document types — that helps a lot in understanding the full scope of what you need.

I’ll answer your technical questions:

How is validation generated when a report is created?

The system integrates with the extension architecture that already exists in Gibbon’s Reports module (the same mechanism used for other customizable report components). At the moment a report is generated, a unique verification code and a CRC code (cryptographically generated, using a secret key specific to the institution) are automatically created and included in the PDF footer, along with the QR Code.

Does this happen automatically for every report generated in modules/Reports?

Yes — but with one important caveat: validation needs to be added once to each report template, through Gibbon’s Template Builder. After that initial step, every time that template is used to generate a report, validation happens automatically, with no further manual action.

One relevant detail we’ve already solved: the system distinguishes between reports generated as Draft versus Final — only final reports receive a real validation code. Drafts don’t create permanent records in the validation database.

How is report data recorded in the validation database?

Each finalized report creates a record in a dedicated table, linked to the student, document type, and school year — without altering any core Gibbon tables.

Can the system validate using the code, CRC, or QR Code?

All three work together, following the SEI pattern you originally described: the QR Code links to the public page with the verification code pre-filled, and the person types in the CRC manually. This two-factor combination prevents anyone from discovering valid codes by trial and error.

How does the public lookup page connect to the generated reports?

It’s a page that requires no login, protected by CAPTCHA, which queries the validation table directly. It never shows the original PDF — only the document’s metadata.

I already have this working end-to-end on a real Gibbon instance, including the public, no-login access.

Regarding the list of documents you shared (Histórico Escolar, Certificados, Atestado de Matrícula, Boletim, Planos de Ensino, etc.) — I have an important question to understand the full scope: are these documents already generated today through Gibbon’s Reports module (meaning templates already exist for each), or would some/all of them still need to be built from scratch? This significantly changes the technical scope, since the validation mechanism itself is reusable across all document types, but each report template (layout, specific data) is separate work from the validation itself.

Happy to keep clarifying any technical questions.

Best,
Tieku