vives-dust / framework

Software IoT stack for the LoRaWAN Micro Weather Station module
1 stars 0 forks source link

Authentication get to populate user object fails with nanoid #168

Open BioBoost opened 1 year ago

BioBoost commented 1 year ago

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.

image

This is inside the get method of the user service class after requesting a jwt token:

image

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.

BioBoost commented 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

BioBoost commented 1 year ago

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!

BioBoost commented 1 year ago

We can't use the previous approach here because the authentication service routes are never hit in this case :(.

BioBoost commented 1 year ago

Hmm

image

BioBoost commented 1 year ago

https://github.com/feathersjs/feathers/issues/2424

BioBoost commented 1 year ago

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.