1000 won’t cut it unfortunately. I need 2700.
https://community.wappler.io/u?period=all
Once I overpass Teo I get a Tesla. We have this agreement.
Always glad I can help towards ditching PHP 
3 Likes
Let me reset your counter 
Good job!
6 Likes
I have absolutely no comeback for that threat so I will just close the door very quite behind me.
4 Likes
lol, now if you can write some kind of magic to provide affordable Node hosting. 
Looks good though, well done.
1 Like
Amazon AWS FREE Tier @brad!
We’ve just hosted a Docker container running Node 14 on EC2 with AWS RDS for MySQL with a few hours learning here and there, a fair few mistakes, and doing the same thing a dozen times… BUT now it’s all working we are not looking back.
We have gone all in on Amazon after decades of hosting our own dedicated servers and cut infrastructure costs by nearly 60% in a single month!
LOL, I can’t see AWS being free for a node site with MySQL database. I would probably get suprised with a big bill. I don’t like surprises.
Anyways, I don’t want to hijack Jon’s thread with my hosting woes.
Anyone ever run into this when trying to run things?
Since I’m on a Mac, I’m guessing this means the Docker container I’m using is running a Linux distribution.
Chemicloud.com allows to host node js apps in all their shared hosting. Pretty affordable. Drawback is that you cannot run some resource intensive packages like puppeteer.
You will need to update the dockerfile in project to include installation of said library.
So everytime you deploy, this will get installed and be available for the Argon2 library.
Unforuntately, I don’t think it’s that easy with versions of GLIBC (the C installation on Linux). It looks like the Wappler Docker container is running version 2.24 (rather than the version 2.25 that the argon2 module seems to want):
This appears to be non-trival to solve: https://askubuntu.com/questions/1021420/glibc-2-25-not-found-on-ubuntu-windows-subsystem-for-linux
From this GLIBC version, I think we can infer that the Wappler Docker container is running Debian 9 “stretch”:
I think just updating it to the current stable Debian, Debian 10 “buster”, might fix the issue since it’s GLIBC version is newer than 2.25. Unfortunately, the wapplerio/node-12 parrent container that I’m using is private on Dockerhub, so I’m not sure how to just edit its Debian parent container to the current stable version. Any idea how to fix this? Maybe changing to the wapplerio/node-14 or wapplerio/node-15 parents containers on Dockerhub (both of which are also private)?
Am I the only one trying to get this working with Docker hosting, or are other people also using Docker hosting and have got it working?
I am not very good with Docker. So what you have shared does make sense and someone from the team would be the best person to respond here.
@patrick
Hi @bradyneal
I faced the same problem. Everything you wrote is correct. The Wappler image that is responsible for the web application is really built on the basis of Debian 9 (although the Mysql image runs on the basis of Debian 10). Using images with a different version of nodejs does not solve the problem, since all these images are based on Debian 9.
I think it would be great if a full Dockerfile was available, which is used to build the image of the Wappler web application. This would make it much easier to make changes if a deep customization of the environment is required.
Great job Jon - this is exactly how I imagined also the Wappler integration. But we need indeed to change also the security provider to be able to handle it as well. @patrick
1 Like
@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.
1 Like
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