FTR, there's already a Jira: https://issues.apache.org/jira/browse/DIRSTUDIO-648
@Emmanuel, did you already started implementing it? On 3/5/20 11:02 PM, Emmanuel Lécharny wrote: > > On 05/03/2020 18:17, Stefan Seelmann wrote: >> On 3/5/20 9:02 AM, Emmanuel Lécharny wrote: >>> On 05/03/2020 07:48, Stefan Seelmann wrote: >>>> On 3/4/20 10:48 PM, Emmanuel Lécharny wrote: >>>>> we can't send a PasswordModify extended operation in Studio, and >>>>> that is >>>>> a bit of a bother for servers that deal with support such operations. >>>>> The only way to get a password injected is to first hash it on the >>>>> client side, then send a Modify operation. This is unefficient, >>>>> especially if the server uses a specific Hash function that is not >>>>> common. >>>>> >>>>> >>>>> What would it take to add such a feature in Studio (more from the >>>>> functional PoV, because technically this is pretty trivial). >>>>> Typically, >>>>> shouldd we have a popup where we ask which user we have to change the >>>>> password for, or is t better to right click on a user and hhave a meny >>>>> entry 'Password modification' ? >>>> A menu entry (maybe within an "Extended Operations" sub-menu) in the >>>> context makes most sense to me. >>> >>> Yes, sounds legit. It might also be worthful to have a popup where you >>> can pick the user then modify its password. >> Hm, I thought if it's just in the context menu of the entry you select >> in the left-hand tree then we already know the user (it's DN). Studio >> also has sufficient search capabilities to find an entry, so also the >> context menu of search result entries can containt the new menu. > > > I think both options are valid. Either you have the entry in the > browser, you right click on it, and get the option to change its > password, or you don't want to bother finding the entry (something that > might be good if there are thousands of entries...), so having the > possibility to have a global menu entry that offers the possibility to > find an entry is good to have. > > > Note that we can send the PasswordModify operation with no DN, in this > case the logged in user will see its password modified. > >> >> When clicking we have of course a popup where to enter the new password, >> and showing the DN. We can reuse the existing password widget in case it >> should be posssible to select different hashing methods, but I don't >> know what the extended op supports. > > The idea is to not select any hash value : the server will do that. All > in all, we just enter the previous password, the new one, and send all > that to the server using the PasswordModify extended operation. > Optionally, we may even not provide a password, the server will then > generate one and return it. > > > > >> >>> Implementation wise, the tricky part is to check that the server >>> supports the extended operation (I think most of them do). >> Shouldn't that be exposed in RootDSE? > > Yes, the PasswdModifyOID (1.3.6.1.4.1.4203.1.11.1) value should be > returned in the RootDSE supportedExtension attribute. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
