Is field ‘inLdap’ really means, that this user is registered both in Mongo and LDAP? Or there can be situation, when user which have flag ‘inLDAP’ set to ‘true’ in fact doesn’t registered there?
I’ve yet to see it but here’s the issue: We have a handful of users (think 20,000+) who are in LDAP(it’s actually a pain in the butt to mass-delete on Crowd – PLEASE make it easy to do in your project) but not in Mongo – so usually the other way around – to use that. There should almost never be a case where that happens – that said, I’ve never actually looked. This is where @plypy would know better than me.
Considering LDAP is the authority (Crowd/JIRA/Confluence) authenticate against it) – that’s not a huge issue – Mongo is there because it’s way easier to develop against than LDAP directly
So, the probably way to check existence - get all users from LDAP, and then ckeck if each user exists in Mongo. Maybe reverse check also will be required.
A user cannot register twice with the same email – so if you find it in LDAP and Mongo – then they are indeed the same user.
Consider using this, it’s a collections implementation. Specifically the set data structure. I assume you’re up to speed on set theory, right? If you find a better way, by all means use your judgement – it’s up to you ultimately…I don’t have a strong opinion. This is an efficient way to compare two data sets and find what’s different between them.
1 Like
Thanks for a link on library, I will use it 
I see, that we need only one ‘sensitive’ field - ‘inLDAP’. I think, we can just put this field to response with another key (for example, ‘isInLDAP’ and send 
What do you think?
You also need the password.
On a client side? What for?
Well, actually now that I think about it – not really…we just need a way to either set a new password and have it hashed and persisted. So just having a text-field for the password (with type password of course)…and a way to trigger a reset for the user…I mean ideally solely having the password reset functionality is good enough for me.
So, for example, if we have user A, which have no admin rights, and user B with admin rights, the user B will have an option to set password for user A? Really? I thought, that ‘password reset’ option means that admin can reset old pass, and new auto-generated pass will be sent on user email for example, isn’t it?
I back-peddled a bit – I think the reset password button – which triggers a reset (confirmation would be nice before doing it) is sufficient.
Which password will be set after reset? That one, which administrator will set?) And how user will find out this NEW password?
Literally just email the user an email to reset their password – we might have to refactor the code here into a helper somewhere:
There needs to be a way to reset passwords in some way.
So, for administrator ‘reset password’ feature will just mean sending email with reset password link for user, right?
Precisely. We’re not changing anything. I would much prefer you not duplicate code if at all possible, for now it’s fine – but will need to be refactored at some point
Okay, now its clear for me I think, I have enough information to continue my work Today I will implement getting data from LDAP/Mongo, than this data will be inserted into some HashMap, with setting flags ‘inLDAP’, ‘inMongo’ (it will be convenient for UI), and transferring this data into DataGrid on UI.
that works – a Set would be handy for seeing what’s not in one but in the other. At least as an intermediate data structure They’re good for things like this, when things may differ.
Just so you’re aware of the scale of data we have in production:
In Mongo: 52,370 and rising
In LDAP: 66,535 and rising
Some of the ones in LDAP and in Mongo are spam users. Probably close to 5,000+ are spam accounts…I wouldn’t be shocked. So whatever algorithm you choose, it has to scale
As I see, there no any public function for searching user, just function for getting ONE user by username. I believe, we must extend this library with such function?
Feel free to add whatever you need