search

inejge / ldap3

A pure-Rust LDAP library using the Tokio stack
Apache License 2.0
226 stars 39 forks source link

feat: introduce serde feature for `Result` types #125

Closed maxswjeon closed 6 months ago

maxswjeon commented 6 months ago

Serde (Serialize) would be a fantastic feature for ldap3.

Implemented Seralize for Result types.

inejge commented 6 months ago

Thanks for the PR, but I believe that ldap3 doesn't need this kind of feature. Before closing the PR, I'd genuinely like to know about your use case -- who is the recipient of the serialized result, and what will that recipient do with serialized data?

(Since about the start of my involvement with this library, I've been thinking about deserializing result entries into structs, but I'm not sure that serde is a good match for the LDAP data model.)

inejge commented 6 months ago

Closing. Feedback is still welcome, of course.

maxswjeon commented 6 months ago

Hi, sorry for late feedback. I am trying to create a http-ldap bridge, which handles ldap queries over http. I was having trouble implementing the serdes features in an external create, so I suggested a serdes feature in this create itself. I am curious of your opition of this usage and implementational details. Thanks for your hard work.

inejge commented 6 months ago

I am trying to create a http-ldap bridge, which handles ldap queries over http.

OK, now I understand more. It seems to me that what you're trying to do would be difficult, starting with the fundamental difference between HTTP and LDAP, that is, state handling: HTTP is stateless, in LDAP everything is defined in relation to a connection/session. (Connectionless LDAP exists, but it's a non-standardized niche protocol which can be practically disregarded.)

Therefore, a bridge would have to run via HTTP/2 or a websocket; in practice, the latter, if you want to use it from the browser. If you're aiming for full generality, probably the simplest way would shuttle raw BER messages between the (web) client and the (LDAP) server. Ldap3 wouldn't help you much on the bridge side since it can't accept and deliver raw packets (and I'm not going to enable raw operation.) So, you'd need your own connection-handling framework. If parts of ldap3 can help you in writing that framework, you can freely use them, of course.

maxswjeon commented 6 months ago

I know that HTTP is stateless, so I would like to group a set of commands in one request.

A payload should consist of

  1. Target LDAP server address and port
  2. Bind Command
  3. Search/Modify/Delete or etc. commands

So one request can run multiple commands, resulting one complete response. This would solve the "stateless" part of HTTP, I think.

Nevertheless, I appreciate your hard work. Thanks.