obgm / libcoap

A CoAP (RFC 7252) implementation in C
Other
777 stars 421 forks source link

Make coap_print_wellknown customizable #1425

Closed anyc closed 4 weeks ago

anyc commented 1 month ago

Hello,

on my device, the CoAP server uses the async functions to act as a reverse proxy for another internal server process with different privileges. I would like to provide the list of resources of the internal server with the list of resources of the main server so a client does not see a difference. To achieve this, I think it would be necessary to register a user callback function which is called instead of the coap_print_wellknown() function and this callback could in turn call coap_print_wellknown() which would have to be made public for this. My callback would then add the URIs from the internal server to the list that libcoap provides.

I could query the internal server during startup and create dummy resources which then would automatically show up but I would prefer to query the internal server on demand only. I think this could also be handy in other cases when coap_resource_unknown_init2() is used to answer requests dynamically.

Another use case for me is that my server grants access to resources based on the DTLS identity and we would like to be able to hide certain resources from users with low privileges. As we store privilege information as part of the session userdata, the session would also have to be passed to the coap_print_wellknown callback.

As far as I understand the corresponding libcoap code, this should be possible with only a few changes. Would you accept such a pull request in principle?

Thank you!

mrdeep1 commented 1 month ago

As a reverse proxy, are you forwarding all requests on to the internal server, or only those that have access based on DTLS identity?

If all, then .well-known/core needs to be passed on as well which would need a code change.

Otherwise, the principle of having a app controllable list of what is returned as a response to .well-known/core makes sense to me.

anyc commented 1 month ago

In my case, I only forward requests that start with a configurable URI prefix. I opened a corresponding PR.

anyc commented 1 month ago

Thanks for merging the PR.

mrdeep1 commented 1 month ago

Now that coap_print_wellknown() is a part of the Public API, and with #1431 providing support for passing .well-known/core to the unknown resource created by coap_resource_unknown_init2() with the GET handler defined, is there any need for the complication of coap_register_print_wellknown_callback()?

It is also possible for the server app to create a resource for .well-known/core with an appropriate GET handler. In this case, with #1431, coap_print_wellknown() does not include .well-known/core in its list.

coap_method_tdoes not include coap_print_status_t's buf, buflenor offset. contextis obtained from coap_session_get_context(session).

The GET handler would just need to follow the principles behind hnd_get_wellknown() (without the locking).

Thooughts?

anyc commented 1 month ago

Sounds good to me. I will give it a try.

mrdeep1 commented 4 weeks ago

1431 has the working version with coap_register_print_wellknown_callback() reverted out as all works with the unknown resource handler.