Open BioBoost opened 1 year ago
I see only one possible solution. Injecting a params prop in the authentication service so we can differentiate in the user service that the GET request is coming from the authentication service and the user id should be treated as a mongo id
This fixes the authenticate route but is does not fix the fact that when we use another service for which authentication is required, the users GET route is hit (to fetch the authenticated user) using a nanoid id while indicated as being an internal request (no rest). Damnit!
We can't use the previous approach here because the authentication
service routes are never hit in this case :(.
Hmm
Again here comes a dirty hack. We can override the getEntityQuery
of JwtStrategy and inject a force_nanoid_id
prop. But this is getting out of hand.
When authenticating to get a jwt token, the username and password are used to authenticate the user. When this process is successful a JWT token is returned containing the subject which is filled with the
_id
by default. We can fix to to contain the nanoid id, no problem here.The problem however is that the jwt is accompanied by the actual user instance. This user instance is fetched from the service
users
after the password/username is validated. However, this GET user/:id is seen as an external rest requests and therefore expects the nanoid id if we use the same implementation for the class get as with the other services.At a moment I can't seem to differentiate between a real external GET and the one coming from the authentication service.
This is inside the get method of the user service class after requesting a jwt token:
What's even more weird is that the user instance is already populated as can be seen in the above screenshot (params). So this is probable the result of the authentication process itself. After which a GET is send to the users service in order to fetch the instance by id, which can in term be used again to load other data.