Hello all, I have a question - I’ve been working on my game which will have a standalone sign-up/login on the Godot side and have been thinking of how I could implement forgot-password functionality without giving out the http_key (as the user wouldn’t have a session when he doesn’t know his password). I’ve thought about using Raw HTTP handlers for some of the functionality but here’s the catch - do I understand correctly that there is no way how I could use bcrypt to encrypt and update the password in my custom Go runtime module? Would I, in such case, have to combine the possibility of such encryption in Lua runtime to make it work? Or am I completely wrong?
Hello @Norvaisas,
This is all achievable at the moment, but it’s not as easy as we’d like to be. There’s a few examples and hints around this that you can follow on this Github issue.
You can absolutely use bcrypt in your custom Go code, you can see an example here.
What Nakama doesn’t currently provide out-of-the-box is:
- An utility function to store the new password, but you can do this with some simple custom SQL (you can use the source link above for inspiration). We’ll consider adding this in the future.
- A way to send a token via email to verify the user’s account ownership. This one can easily be achieved using a third party provider like SendGrid (or another of your preference).
The custom raw HTTP handler feature that was introduced recently now allows to implement the password recovery flow end-to-end (minus the email sending) using Nakama. We’re planning to improve documentation and provide a full example sometime in the future.
Just to reiterate, you’d need to implement the following steps:
- A simple password recovery page with an email and/or username form that is served by the raw HTTP handler.
- Generate, store and send a one-time-code to the account’s email if the user provided one and it matches with an existing account.
- Another endpoint in your raw HTTP handler that receives the token via http param, validates it (ideally you have a time expiry on the one-time-code as well), and prompts the user for the new password. Submit it alongside the token and re-validate it, and if correct then proceed with password replacement and show a simple success page.
All the above assumes that you’ve correctly secured Nakama with HTTPS.
Best.
Thank you for a quick response. However, regarding the use of bcrypt in the custom runtime module - I’ve tried importing the bcrypt package into one of my modules and I get a bunch of errors that are described in the Dependency Pinning section of the Nakama documentation. However, throughout yesterday I haven’t managed to find out the cure for that.
The thing is that I am using W10 and the only way that I can build the plugins is through Dockerfile. My docker configuration is alright, it follows all the required steps and the plugin builder version matches the nakama version.
However, whenever I load up the container, I get such errors:
nakama-1 | {"level":"error","ts":"2025-03-14T17:35:41.877Z","caller":"server/runtime_go.go:2996","msg":"Could not open Go module","path":"/nakama/data/modules/backend.so","error":"plugin.Open(\"/nakama/data/modules/backend\"): plugin was built with a different version of package golang.org/x/crypto/blowfish"}
nakama-1 | {"level":"error","ts":"2025-03-14T17:35:41.877Z","caller":"server/runtime.go:670","msg":"Error initialising Go runtime provider","error":"plugin.Open(\"/nakama/data/modules/backend\"): plugin was built with a different version of package golang.org/x/crypto/blowfish"}
nakama-1 | {"level":"fatal","ts":"2025-03-14T17:35:41.877Z","caller":"main.go:201","msg":"Failed initializing runtime modules","error":"plugin.Open(\"/nakama/data/modules/backend\"): plugin was built with a different version of package golang.org/x/crypto/blowfish"}
I only need bcrypt in my password_reset.go custom module. I’ve tried all of the things in the Dependency Pinning section and nothing helped.
Have You possibly dealt with something like this in Your experience? (I’m kinda new to this whole Go thing, trying to give it a go)
Alright, it’s probably one of those times where entering it into forum made me delve into the issue a little deeper. The thing was that in the go.mod I wasn’t using the same version of the The Go Programming Language as used in the Nakama