@George @patrick Does this mean you have plans to add support for the argon2-backed “Password Hash” formatter and the “Use Password Has Verify” checkbox to native NodeJS back-end Wappler? Or does it mean you plan to add better support for Jon’s extension code (see, e.g., Docker container GLIBC issues above)?
Adding solely argon2 to the backend although being a great addition to the product would still mask the fact that we can’t plug into the Security module. So it would be better for everyone that that part is resolved and then we can skip the workaround.
Edit: In case it’s not clear I would also prefer to have the argon2 module maintained by others 
Just not before the extensibility for Security Provider is built.
Were you able to find a solution to this issue? I just bumped into this same error while trying to implement this.
No sir. Maybe @patrick has plans to allow Jon’s extension code to be better supported by Wappler or plans to implement this in native NodeJS Wappler? I would certainly be very happy to hear that.
As a workaround, could you do the following to add Security Provider support (as suggested in the first post)?
In your login step, check the password using @jonl’s extension then use a query to pull a value from the DB for that account that constitutes a password to be used with a Security Provider login step? You can then use Security Provider’s restrict and identity steps. Not entirely native support, but not far off.
Don’t get me wrong, I would still like a native Argon hash formatter and integration into Sec Provider for NodeJS
I’m trying to use this with a docker project and am hitting the GLIBC_2.25 issue too. Would love to know if anyone solved it but also would like to bump this being integrated into Wappler natively. @patrick @George
We have the same problem, we prefer to use packages without native bindings, we cannot guarantee that those packages will work or build everywhere.
So is this not happening at all? If not, that’s fine but it would be good to know.
Not fine actually if it is not to happen in my opinion. It should happen. Wappler is expected to support better hashing algo out of the box. They’re a good software people - can always get better!
I agree, but knowing is better than waiting in futile hope…
I do find it really frustrating that it was introduced for PHP just before much of the feature development shifted to being NodeJS. The problem is that it becomes very hard to transfer those projects to NodeJS and make use of Wappler’s full feature set because passwords are already generated and stored with Argon hashing. You’ll inevitably end up annoying end users who then need to reset their password.
Hi Ben,
You can avoid that entirely.
1 Leave a small API for your php project running that checks if a password entered can be validated against the old hash. Doesn’t even have to be a Wappler project, it could just be a plain php file loading the needed libraries.
2 In the new project when submitting the password form the first thing you need to do in the SC(besides validations and that stuff) is check if the password for that user starts with $argon2id$
3a If it does, call the php API and verify the user/password and if true rehash with your new algo and update the password field and go to 4.
3b If it doesn’t start with $argon2id$ validate against new algo and go to 4.
4 Log the user in.
My perspective is different.
We’re a dev shop - typically we’ll do a couple fresh projects per year - so for us if we are able to use argon in the next project - it’ll be awesome.
We’ve had a client request where they did not want SHA - so we ended up using aws cognito.
Good catch Brady,
I think we should provide more options to choose the right docker image.
And since we fully generate the Dockerfile and npm install is done each time, there isn’t much need for separate wappler/node docker images, we might just as well link to the original node docker images.
Also we can add more options for node version, debian version (strecht, buster, bullseye) and type (slim, alpine) - it won’t be veyr clear to theregular users but we hope to add the right defaults 
@George Maybe you and your team could implement this feature right away with this “Docker update”? 
Edit: sorry, forgot to add link to topic - Dockerfile re-writes
Don’t you dare add a fix tag here @Teodor
This was my main source of no-income!
Glad you guys added a streamlined implementation!
Ughh i hoped you won’t notice this, so we can secretly steal it from you 
If by steal you mean supporting it. Yeah please steal from me!
Well well well…it seems mine is still premium. With mine people can choose their memory and time cost, parallelism, and length.
Only because of that it is well worth the cost of it because when the wifey asks me to do something for her on the computer I crank up everything to 128000, create an account and render my computer useless. It’s also good to melt it down if you need an excuse to buy a new macbook pro.