Addict: A Full REST API for Active Directory in 30 Seconds
github.com> drop-in REST API
> GET /user/:user/exists
Wat. Use HEAD. Seriously.
Also, what is ":user" - how do you define the way an account is found in the tree?
How do you handle complex trees with potentially conflicting values for the attribute you use as 'username' ?
Why are their dedicated endpoints for password, expiry, enable/disable/unlock. These are all just attributes on the user object.
> Also, what is ":user" - how do you define the way an account is found in the tree?
That checks sAMAccountName, which is unique. Searches that can return multiple results will do so.
> Why are their dedicated endpoints for password, expiry, enable/disable/unlock. These are all just attributes on the user object.
It wouldn't be very user friendly to require a PATCH so a user can change a password. All of these operations are quite granular. You aren't going to enable an account and change a password at the same time very often.
The overriding drive in building this was ease of use, because that bugs me with AD. I'm definitely open to suggestions, though :)
> for Active Directory and LDAP implementations
> That checks sAMAccountName, which is unique
Only in Microsoft's schema. If you want to work with just AD, thats fine, but you shouldn't claim to be LDAP compatible if you only work with a single vendor's schema.
> It wouldn't be very user friendly to require a PATCH so a user can change a password
Why? It's a REST API, you're talking to it from code, you aren't asking users to write curl requests.
> You aren't going to enable an account and change a password at the same time very often.
I see you've never worked in a support environment before. If the account becomes locked, its usually because the user tried the wrong password too many times. So, they contact support who can unlock it, and invariably will need to reset the password at the same time.
> I'm definitely open to suggestions
Well I think you need to decide if its targeting AD specifically or any LDAP directory server. If it's the latter, it needs to be a lot more configurable .
Fair enough. I updated the readme for now, and will work on those points!
For what it' worth, I definitely understand the basic premise of your project. I'm a big believer that people end up re-inventing a lot of things that Directory Services has had working since the late 90's simply because it's too different to what they're familiar with.
Well, thanks for that. I've actually had to deal with it for quite a while, believe it or not. And the current design is working out for my use. I do hope it does help others.