> Hi Hans
>
> Since you specifically mentioned about groovy service, I would think
> it is true for other services as well.
>
> It would possibly be happening, if the service itself is declared with
> auth=false, so no token check is happening and hence userLogin is not
> retrieved from the token.
> Can you confirm if this is the case? The userLogin is added to the
> service call before delegating the service call to dispatcher after
> jwt has been verified. But in case of auth=false, services, auth is
> bypassed and hence userLogin is not set.
>
> I guess the key here is to bypass token validation if, and only if,
> the Authorization header is absent, otherwise perform validation. I
> had a discussion about this with Jacopo as well and here is what can
> be done (applicable for */services *endpoint ) -
>
> If auth=false and *Authorization* header is */present/*, validate
> token and return error if invalid. Else set userLogin in context and
> delegate the call to dispatcher.
> If auth=false and *Authorization* header is *absent, *just call the
> service. The service will be executed */without/* userLogin in context.
>
> I will try to work on this change in the next couple days.
>
> Best,
> Girish
> HotWax Systems
>
>
>
>
>
>
>
>
>
>
>
> Best,
> Girish
> HotWax Systems
>
>
>
>
>
>
>
>
> On Tue, Sep 29, 2020 at 6:20 AM Hans Bakker
> <
[hidden email] <mailto:
[hidden email]>> wrote:
>
> Hi Girish,
>
> thanks for your last email, that is working now too....
>
> however....another question,
>
> If i call a service using the token i obtained earlier, i see that
> the
> userLogin map in the groovy service I called, is null
>
> can you set the login map to the userLogin of the token that was
> used so
> we know who the user is?
>
> Thanks, Hans
>
>