{ user } returned from getEntity breaks when implementing anonymous auth

[ericuldall]

I've implemented anonymous auth so that I can have tiered data availability in different sections of my api. Some data is visible to logged out users, and logged in users will be subject to RBAC.

I have a hook that restricts properties if either the user object is:

• not your own
• you are logged out
• you don't have sufficient RBAC permissions to view that data

The problem, I think...

I believe that when I call reAuthenticate in my client that calls the jwt strategy and getEntity is getting picked up as an anonymous call, therefore my { user } object stored in my client authStore is truncated, this is causing portions of my client to break.

Solutions?

feathers/packages/authentication/src/jwt.ts

Lines 107 to 126 in 82d30fd

	async getEntity(id: string, params: Params) {
	const entityService = this.entityService
	const { entity } = this.configuration
	debug('Getting entity', id)
	if (entityService === null) {
	throw new NotAuthenticated('Could not find entity service')
	}
	const query = await this.getEntityQuery(params)
	const getParams = Object.assign({}, omit(params, 'provider'), { query })
	const result = await entityService.get(id, getParams)
	if (!params.provider) {
	return result
	}
	return entityService.get(id, { ...params, [entity]: result })
	}

Do we need the check for params.provider on line 121 ? I'm wondering in what circumstances would an authentication request NOT come from a provider? Seems like if we get a valid JWT in the request and can return the user object we should do so outside of the context of any provider.

Does my logic track here? Any other known workarounds @daffl ?

Another thought... Maybe auth strategies should have their own unique provider? { ...params, provider: 'authentication' } that way we could be more empowered to know when we're dealing with requests related to authentication vs other requests to the entity service from a rest or ws provider.

[ericuldall]

Confirming this custom jwt strategy addresses the issue:

export class CustomJWTStrategy extends JWTStrategy {
    async getEntity(id, params) {
        const entityService = this.entityService
        const { entity } = this.configuration

        if (entityService === null) {
            throw new NotAuthenticated('Could not find entity service')
        }

        const query = await this.getEntityQuery(params)
        const getParams = Object.assign({}, { ...params, provider: null }, { query })
        return entityService.get(id, getParams)
    }
}

@daffl do you think this should be the default logic? Is there any reason why it shouldn't work this way?

[daffl]

There was a reason for this but I don't recall why at the moment. The provider behaviour with authentication is something that keeps coming up, unfortunately it has also been a bit of a game of whack-a-mole in that fixing one way of doing things will cause other problems and vice versa.

[ericuldall]

Well, I think since the code is easily extensible it's not too big a worry. My issue is solved with a custom strategy.

[daffl]

Going forward I'd like to provide the option to get the user information from your own function instead of a service (where you have to worry about how it is being accessed). That way you could call the database directly or use an external API etc.