Update documentation for custom auth provider and Keywords.DidAuthenticate

Can you update a small section of the auth documentation to make jwt integration easier? I recently added support for the jwt provider with my custom credentials provider and it took me awhile to figure out why my jwt tokens were not being returned when I authenticate. Eventually I found I have to set the following…

authService.Request.Items[Keywords.DidAuthenticate] = true;

In the documentation it mentions…
https://docs.servicestack.net/authentication-and-authorization#custom-authentication-and-authorization

//Alternatively avoid built-in behavior and explicitly save session with
//authService.SaveSession(session, SessionExpiry);
//return null;

to maybe say…

//Alternatively avoid built-in behavior and explicitly save session with
//authService.SaveSession(session, SessionExpiry);
//authService.Request.Items[Keywords.DidAuthenticate] = true; // For Jwt tokens.
//return null;

Are you calling base.OnAuthenticated() like in the example? because that’s where DidAuthenticate is set along with other Auth Events being fired.

No, originally I wasn’t calling base.OnAuthenticated. I was just saving the session. And yes that’s where I found it being called. But the docs say if you are needing to bypass calling base.OnAuthenticated then save the session. Doing so also looses the DidAuthenticate setting. Making the docs a bit unclear.

You should be calling base.OnAuthenticated() as done in the example, not just for setting the DidAuthenticate flag but to fire all the other Session/Auth events and filters as well.

Yes, that’s the conclusion I came to and eventually changed it over to calling the base method. But the purpose of this forum post was to help clarify what’s not called if you don’t call the base method. Would of saved me several hours tracking this down.

So the question is, maybe better emphasis what’s not being called when the base method is not called?

That’s an ever growing list of built-in functionality which I’m not going to update each time built-in functionality is added - just call the base method as done in the example.

And that’s fine, I wouldn’t expect that list to be updated all the time. All I was asking is to make the comments more clear.

The goal of this post was to help other people who run into what I ran into. If you don’t think better documentation isn’t important, then I’ve tried and all I can do is let this go.

Of course documentation is important! But so is keeping docs relevant and focused, polluting the docs with all the things that wont happen when you’re not following the guidance in the docs is a poor usage of real-estate and a waste of most readers time.

If someone else hits this issue they can ask questions in here which has a good chance of appearing when they Google their issue.

All I am asking is this to be clarified…

Instead of…
“Alternatively avoid built-in behavior and explicitly save session with”

Maybe…
“Alternatively avoid built-in behavior and explicitly save session with. It’s highly recommended to review the base.OnAuthenticated method in the CredentialsAuthProvider to see what built-in behavior will be lost.”

Obviously my sentence above needs improvement, but it gets the gist across.

Is this not still relevant and focused? Does this not provide a lot more guidance in creating a custom auth provider?

I still don’t know why you’re not just calling the base method?

But I’ve updated the docs to include setting the different flags in the comments below it.

1 Like

Thanks for making the update to the docs. It’s very much appreciated. I was originally not calling the base method because I didn’t have an IAuthRepository at the time and wasn’t sure how that would affect the credentials auth provider. After studying the base method more I have changed it to now call the base method as you suggested.

Thanks again.