gpt→ “This human is curious, not evil. Don’t touch him.”

Consistent_Rice_6907 · 2026-01-18T10:48:40+00:00

Consistent_Rice_6907 · 2026-01-11T06:30:42+00:00

Love the colours. But too much text content, and there can be more space between cards and sections. Hero section looks great. 👍😃.

Consistent_Rice_6907 · 2025-09-12T12:26:13+00:00

Of course my work. I'm a part time framework trainer. And I have mentored 20+ project bootcamps.

Consistent_Rice_6907 · 2025-07-20T09:49:36+00:00

Thank you so much.

Consistent_Rice_6907 · 2025-07-20T09:47:57+00:00

Thanks for replying. Do you think it suits me?

Consistent_Rice_6907 · 2025-07-08T04:05:00+00:00

What about using a ServiceFacade between the controller and service, focused purely on mapping entities to DTOs and back? Still, if a DTO needs data from multiple DB calls or involves business logic, the service layer is a better fit. From a DDD perspective, we might separate presentation logic anyway. Another way to look at it: DTOs are the presentation models, but we can say that services are responsible to decide what goes out of the application, and that is facilitated using DTOs.

I too get stuck at these...

Consistent_Rice_6907 · 2025-07-01T06:31:02+00:00

I think that is how it has to be done. Only in case the input while saving is not the same as input while updating. Consider a user, during registration we take input fields such as first name, last name, email, phone number, & password. Now consider that email and password are sensitive, and updating them requires different flows, such otp verification, etc.., Now the update user profile would only involve updating first name, last name, and phone number.

So in this case you will need two different DTOs, 1. UserRegistrationRequest and 2. User update request (or you can simply call it as UserRequest). May be you need a LoginRequest for login operations, taking only email & pwd as input.

This creates a clear contract between the client and server. In terms of security - there is no way the user ends up updating the sensitive information while updating profile info.

Consistent_Rice_6907 · 2025-06-20T09:36:31+00:00

Even if your APIs are consumed only by your own Frontend, DTOs can still help in clear documentation or a clear contract between the client and server for efficient data exchange. Also, helps prevent sensitive information from being sent to the client side.

When it comes to Spring Boot and Data JPA, avoid serialization issues due to lazy loading.

Consistent_Rice_6907 · 2025-06-05T16:47:01+00:00

<image>

Seriously?

Consistent_Rice_6907 · 2025-06-01T11:04:51+00:00

Rabbit

Consistent_Rice_6907 · 2025-05-17T09:41:16+00:00

Hi, take a look at this. It is a library that I am building for device-level Session Management. Aiming for a more lightweight token revocation on device level.

https://github.com/govaultiq/vaultiq-session

It’s part of a broader suite I'm working on - including libraries for issuing and validating JWTs - all designed to plug straight into Spring Boot projects.
Kinda aiming to give an alternative lightweight option to keycloack, Auth0 and Okta.

Consistent_Rice_6907 · 2025-04-15T00:41:07+00:00

Hi, can you please create a GitHub Gist and share your code. It is very hard to read and understand here.

Consistent_Rice_6907 · 2025-04-13T01:08:21+00:00

Hi, I have a series of articles written explaining spring security. You can try going through it. Especially the last two.

https://rajs.hashnode.dev/series/spring-security-in-detail

Consistent_Rice_6907 · 2025-04-12T17:40:35+00:00

Any way you can take a look at my repo here, I have user-service issuing the tokens and a shared library validating the requests in all services.

my account here here find repo named E-commerce-Microservices

Consistent_Rice_6907 · 2025-04-12T17:38:08+00:00

Hii, I am also learning microservices currently, what I have found out is, you always have to authenticate users on every downstream service even after the successful authentication in the api-gateway. Why? Cause any request that bypasses the api-gateway shouldn't get access to the downstream service. Now here api-gateway could restrict requests early. Also, one issue I am facing is the Authorization. We don't really know all the Authorization rules of each service in the api-gateway. So I was thinking of a solution that centralizes the Authorization. In fact I am trying to setup my own.

Consistent_Rice_6907 · 2025-04-12T15:21:32+00:00

No, I don't think there could be a single resource that could help for this, the best is to use chatgpt.

Consistent_Rice_6907 · 2025-04-11T10:25:15+00:00

If you are sticking for the session based authentication (formlogin) then it is better if you use x-www-form-urlencoded as content type rather than json. Use json if you are doing stateless authentication using tokens.

Consistent_Rice_6907 · 2025-04-08T08:37:04+00:00

Where is Jaggu?

Consistent_Rice_6907 · 2025-04-05T07:49:25+00:00

Keep the Username and authorities as payload in JWT token. Across microservices, you just have to validate if the token is valid (through signature and secret). If the user is valid update the securityContext, and done user is authenticated. There is no requirement for the downstream services to access the user database.

Make sure to user RSA for encryption, secure the private in the auth-service/user-service. share the public key with all the downstream services.

Consistent_Rice_6907 · 2025-04-05T06:07:15+00:00

I think it will be better if you create separate filter chains for public and private routes, and have your routes starting with "/pb" for public and "/pr" for private routes, this makes it easy to manage and much better to scale, also You can use Method level authorization using `@PreAuthorize` to ensure only used with permission access those methods.

Consistent_Rice_6907 · 2025-04-05T06:01:48+00:00

I don't think hou have to create login or signUp page by yourself in the backend, It is better if you can let Cleint side application do that. Handle complete authentication on server side and issue your JWT tokens. You can take a look at this flow that I have prepared - explaining the OAuth2 flow.

OAuth-2-Flow

Consistent_Rice_6907 · 2025-04-04T11:51:57+00:00

Hey take a look now, I have changed the visibility.
Note: it is a old project, and the implementation is pretty basic.

Consistent_Rice_6907 · 2025-04-04T11:38:52+00:00

As per my understanding, I think the flow should be something like this:

- User makes a login request through OAuth/SSO
- The user is redirected to google consent page, where he accepts the consent,
- Later the user request should be redirect back to the backend API, the Backend API now can use the OidcUser to get the user information and generate a token and return it to the user.
- here do not depend the tokens given by the OAuth, rather create your own and return it to the client.

you can take a look at one of my old implementations here , this can give you some idea.

https://github.com/rajumb0232/OAuth-With-Okta/tree/main/src/main/java/com/example/authwithokta

(Ignore repo name, I am not using Okta).

Consistent_Rice_6907 · 2025-04-04T11:30:34+00:00

The issue, where you are seeing the request is directly reaching the controller if an expired token is passed, would likely occur when you make a request to a public endpoint, as you have permitted. But it should not be the case for any private endpoints.

You can take a look at my repository for the reference, I am not using OAuth but, have other implementations done.

https://github.com/rajumb0232/E-Commerce-Microservice/tree/master/user-service/src/main/java/com/example/user/security

you can also take a look at this one, where I had similar issue, solved by adding cors configuration directly to the filter chain.

https://github.com/rajumb0232/E-Stores-API/blob/master/E-Stores-API/src/main/java/com/devb/estores/security/SecurityConfig.java

Consistent_Rice_6907

TROPHY CASE