What is the difference between overriding an api vs overriding a function? For example consumeCode as a function vs consumeCodePost as an api? What are the intended use cases for each option?

hey @User that's a great question. So there are two ways the recipe functions are called: - via the api functions - via the functions exposed by the recipes which you can call in your APIs If you override the override.functions, you will be affecting logic for both the calls above. On the other hand, if you are overriding the API, you will be affecting just the API call. One more difference is that apis may call multiple recipe functions in them. For example, the sign in API calls the sign in recipe function and the session's create new session function. So if you override the sign in API, you can do something before or after both those recipe functions have run. On the other hand, the recipe function for sign in (which is called by the sign in API), doesn't call any other recipe function. So if you want to do something post sign in, but before a session is created, you should override the recipe sign in function and not the API sign in function. Overall, if your modification doesn't depend on the request object, you should try and override the recipe function, else you should override the api function

My modification in this instance was that I wanted the email address inside the accesstoken payload. Solution was therefore to use the consumeCode function override to add the email to the context after successfully using the code. Then in the session create function add the email to the access token payload by pulling it from the context. There was a similar example in the docs but it was confusing to start with as I already had a consumeCode api override and that gets called in a different order.

You are right about how to get the info from request obj to create new session function. You have to use the context object.

That’s what I figured however the first example in the docs I read showed the api override. But I now can’t really see a reason to ever use the api override. Seems you want to pretty much always default to the recipe function

Yes. That’s true. API override would be useful to comsume some custom Params from the request body or send a custom response. And also add to the user context object

Ok makes sense thanks.

Seems like you really understood the concept well! How much time did it take to get this understanding? Any feedback on how to make it easier?

Spent about 4 hours implementing it today. Am up and running and deployed now.

That’s great

The api reference in the docs was probably the most confusing and least useful. The examples obviously much more helpful

Are you talking about the swagger api reference?

No the swagger docs are fine. The node js api reference was hard to read

Ah I see. The ones in /docs/nodejs?

I’ll just check the url..

I see. Fair enough. That’s only meant to know more about a specific function. Like the Args and output of a function. Not really a guide

Yeah.. I had a look round them but went back to the guides

Thanks for the feedback

Im now considing how to implement a few more advanced features. 1: alerts / logging when high volume of login attempts 2: account lock / timeout on failed logins

I see. I have ideas on how those can be implemented. Will do a small write up soon

great.. ill look forward to it.. for now im up and running with a good token system.. I can throw away the one I was half way through writing 🙂

I’ll probably do them as a blog post for our site. Seems useful for others too

Im considering deploying a docker image for production on heroku.. I don suppose there is a blog post on heroku hosting anywhere?

There isn’t 😦

perfect thanks

Thanks