Four Bugs Stood Between Me amd "Sign in with Google"

**Análise Técnica: Arquivo de Projeto Revit BIM - Revisão do Modelo**

Olá, membros do webmastersmz.com! Hoje, vamos discutir um tópico técnico importante relacionado aos arquivos de projeto Revit BIM. O Revit é um software de modelagem de edifícios e infraestruturas desenvolvido pela Autodesk, que permite criar modelos de construção com precisão e detalhe.

**Model Review**

O processo de revisão do modelo é uma etapa crítica no ciclo de vida de um projeto de construção. Envolve a análise e validação do modelo de edifício para garantir que ele seja preciso, consistente e completo. Isso é fundamental para evitar erros e problemas durante a construção.

**Breakdown**

O breakdown é o processo de decomposição do modelo de edifício em componentes individuais, como paredes, colunas, tetos, etc. Isso permite que os especialistas em BIM analisem e validem cada componente separadamente, garantindo que eles sejam corretos e coerentes.

**Pontos Principais**

- **Precisão**: A precisão é fundamental no processo de revisão do modelo. Erros pequenos podem ter consequências significativas durante a construção.
- **Consistência**: A consistência é essencial para garantir que o modelo seja coerente e fácil de entender.
- **Completo**: O modelo deve ser completo e incluir todos os componentes necessários.

**Soluções de Alojamento de Alta Performance**

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em https://aplichost.com. Com mais de 15 anos de experiência em hospedagem de sites e aplicativos, a AplicHost oferece planos de hospedagem escaláveis, seguros e confiáveis, com suporte técnico 24/7. Não hesitem em nos contatar para mais informações sobre como podemos ajudar a melhorar a performance do seu site ou fórum.

**Debate no Fórum**

Essa é uma discussão técnica importante para todos os especialistas em BIM e construção. Se você tem alguma dúvida ou comentário sobre o processo de revisão do modelo ou o breakdown, por favor, compartilhe conosco no fórum webmastersmz.com! Estamos ansiosos para ouvir suas opiniões e aprendermos com vocês.

Four Bugs Stood Between Me amd "Sign in with Google"



Tópico: Four Bugs Stood Between Me amd "Sign in with Google"
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
Summary: I had a rough time adding Google login to my app, Kenning. It took me a while to figure out four issues that were causing problems. These issues were not related to each other and were not covered in any tutorial I read.

My second post about building Kenning, this phase is about OAuth2 login. I thought it would be easy. It was not. I had to deal with four confusing bugs.



Bug 1: the client ID with a hidden character


Google did not accept my login. It gave me an error message saying "Error 401: invalid_client". I checked my client ID in the .env file. It looked correct. I had copied it from the Cloud Console.

When I looked at the actual request that was being sent, I saw the problem. The client ID had a hidden character at the end. This character was a carriage return, represented by %0D in URL encoding. My .env file had Windows line endings (CRLF), and that extra character was being included in the value.

The fix was switching my editor's line ending setting from CRLF to LF and re-saving the file. (You can also strip it from an existing file with sed -i 's/\r$//' .env, but the actual cause was the editor's line-ending mode, not a one-off corrupted file.)

What I learned from this is that just because something looks correct does not mean it is correct. I should have checked the actual value instead of just looking at it.



Bug 2: the user service Spring never called


After I fixed that bug I was able to complete the login process. But I noticed that no user was being added to my database. I had written a custom user-loading service, and it was not being called.

I looked into the auth object that Spring had built after login and saw that it had an authority called OIDC_USER. This told me that Spring was routing the login through the OidcUserService interface. My custom service was extending the wrong base class — DefaultOAuth2UserService instead of OidcUserService — so it was simply never invoked, even though it was wired in correctly.

To fix this I changed my custom service to extend OidcUserService instead. This fixed the problem.



Bug 3: the CSRF cookie that needs to be asked for


After fixing that, login worked end to end. When I tried to upload a file, I got a 403 Forbidden error. I had set up CSRF protection on purpose, so this made sense in principle — except the cookie it depends on, XSRF-TOKEN, was never being written in the first place.

It turns out Spring Security 6+ defers writing that cookie until something in the request actually reads the token. A GET request that never touches it never triggers the write.

To fix this I wrote a filter that forces the token to be read on every request, which triggers the cookie write.



Bug 4: two cookies, same name, different values


I spent a lot of time on this one. I kept copying the X-XSRF-TOKEN value into a manual request and it kept getting rejected, even right after confirming in DevTools that the cookie existed.

Looking closer, DevTools was showing two separate XSRF-TOKEN entries with the same name but different values — one with an empty partition key, and one partitioned under resource://devtools. I had been copying the DevTools-partitioned one, which isn't the value the browser actually sends on a real request. Once I copied the other one — the unpartitioned cookie — it worked immediately.



A thing I haven't solved yet


Before any of this, I tried using the spring-dotenv library to load my .env file automatically instead of exporting variables by hand every time. After adding it, login stopped working, and I genuinely don't know why — I never confirmed whether it was even loading the file, or something else entirely. I removed the dependency and went back to exporting variables manually. If anyone's gotten this working alongside Spring Security + OAuth2, I'd like to hear how.



What actually mattered


None of these bugs were caused by Spring or OAuth2 being badly designed. Each one had a clear explanation once I found it. What would have saved me time is checking the actual outgoing request the moment something failed for a reason that didn't make sense, instead of trusting echo output or DevTools at face value.



And the frontend?


Comparatively quiet, which I'm counting as a win. I used Angular and PrimeNG to build the document list and chat screen. Once I had the right cookie and header names configured, the whole CSRF back-and-forth from Bug 3 just worked automatically on every request, because the frontend handles this pattern natively.

Next up: a reader on the last post called the chunk-dilution theory exactly right and suggested keeping chunks to one topic each. So up next is testing that properly — comparing chat models, embedding models, and chunking strategies head to head, local and cloud, on quality, speed, and cost.

Building Kenning in public. Corrections welcome — especially on the spring-dotenv mystery above.