The way I proposed kinda "just works"™ – Basically you’d have an environment variable similar to the way rails does things where you’d have NODE_ENV=production and ldap would be required – the only case I’d say we should enable is for NODE_ENV=test or NODE_ENV=production. Your way requires I muck with config files…why add to the workload? Check out this stackoverflow post for an idea how to implement this.
Ok, I will use NODE_ENV.
Good luck 
But also there must be an option, how to ENABLE ldap for development environment. It will be disabled by default, but there can be situations, where user will want to work with ldap in development. What do you think about it? We can use variable like LDAP=true, so when user will want to use ldap in development, he can start app using: LDAP=true node app/app.js
I would actually recommend you use a parameter in conf.js
My idea behind ID-82 wasn’t so much to disable or stub out LDAP when in development mode, but to refactor the Dashboard’s model code so that it the Mongoose models would only talk to LDAP if an LDAP server was configured. That way, an environment that has no need for LDAP can safely ignore setting it up.
1 Like
reverted – @dmytro_trifonov, could you implement this?
Ok, sure. So, we need to add parameter, such as ‘ldap.enabled’ to conf.js, as I proposed before, right?
@dmytro_trifonov that’s what I would do. Make sure that ldap.enabled defaults to true, and that nothing will break if ldap.enabled = false and the other LDAP config options are undefined.
For example, this should be a valid LDAP block in conf.js:
"ldap": {
"enabled": false
}
Thanks!
3 Likes
Ok, I will do that.
But what about next situation: let’s imagine, that there are user, which DON’T WANT to use ldap for development. He can set 'ldap.enbled': false in config, by “LDAP” module also added to package.json, and to resolve this dependency, he also must install next libraries: build-essential, libldap2-dev, and uuid-dev (they are required for building LDAP module). I think, there must be solution for users, who don’t want to use ldap, and don’t need to install LDAP module with required libraries.
What do you think about it?
One of the solutions - remove LDAP dependency from package.json, so users, who want to use ldap, may resolve this dependency manually, by running npm install LDAP@version.
@dmytro_trifonov, you seem to have dropped the ball on your ticket…as it stands you’ve completed zero tickets…since it wasn’t done correctly…and it’s something I could actually use on my system…since slapd doesn’t seem to want to install on my laptop (works fine on nitrious)…but point is: I need it and well many others who will work on it do as well…it’d eliminate the need for me to keep a nitrious.io box around.
Kinda a bit time-sensitive too. Open up a new PR and if it’s well-tested and works – I’ll gladly merge it. But this is time-sensitive, I have to make my final decision soon…
I committed my changes before, but I didn’t receive answer for details, how to implement this option.
In my commit, LDAP will can be disabled by setting ldap.enabled to false
Created pull request: https://github.com/openmrs/openmrs-contrib-id/pull/73
will wait for answer
I will check and if it works – it solves a need I have right now – and will get merged immediately.
Whomever is chosen, you will want to heed the wireframes when making any UI changes – some of which are currently merged – some are in a state of being broken…but the important part is that we need a way to be able to associate several 3rd party logins – not just one. OpenMRS ID will expand in its purpose – so we need to be able to grow as it does. I am hoping to have all the UI changes that were written during Google Code-In (GCI) merged before coding begins in May. This way you have a jumping off point – for 3rd party login – the easiest way would be font awesome icons and anchor tags using the bootstrap button classes. We will be excluding the mailing list functionality.
I am going to ask you to plan everything before you write code – when you are accepted (whichever student is chosen), the steps you will take during the community bonding period will be polishing your project plan, and doing wireframes. I want this summer to be focused and I want you to be successful–and part of ensuring that is having a plan of action. I want weekly milestones-- if you need to change them, that’s fine…but I want a focused summer!
1 Like
@r0bby
As i said before, i worked on basic implementation of Two Factor Authentication. I pushed my code here:
github, branch name tfa-test
This implementation just an example, without emphasis on design. I’ve update user model with special options for TOTP, added separate page “security” for changing TFA settings, and implement OTP validation.
Steps to check:
- Create new account
- Go to the profile page
- Go to “security”
- Click “enable” TFA button
- Enter password, scan your profile QR-code using Google Authenticator, generate code in app and enter to page
- Press "Proceed
- See the result
Next steps for me: implement TOTP validation on login. Also I included screenshots: screen 1 screen 2 screen 3 screen 4 screen 5
Great work @dmytro_trifonov!