Open chrysn opened 7 years ago
@ChangSam, please open a different issue for questions unrelated to previous topics.
The incoming message carries a .remote property which indicates the address of the requester in a transport-specific fashion. Proper security can be established using the OSCOAP protocl (see the contrib/oscoap-plugtest examples, but beware that the specification itself is not finalized yet and the API is still in flux) or CoAP over dTLS, which is currently work in progress in aiocoap.
Hello chrysn: thank for your reply , you means that the CoAP client requests will contain it's IP address , so that the CoAP server will know that if the client is authorized or not, am I right??
This mechanism is in the CoAP or OSCoAP standard ?
2017-04-24 14:36 GMT+08:00 chrysn notifications@github.com:
@ChangSam https://github.com/ChangSam, please open a different issue for questions unrelated to previous topics.
The incoming message carries a .remote property which indicates the address of the requester in a transport-specific fashion. Proper security can be established using the OSCOAP protocl (see the contrib/oscoap-plugtest examples, but beware that the specification itself is not finalized yet and the API is still in flux) or CoAP over dTLS, which is currently work in progress in aiocoap.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chrysn/aiocoap/issues/70#issuecomment-296539641, or mute the thread https://github.com/notifications/unsubscribe-auth/AQJUytYuDfo2agLL7hrxLSkQdj8ry5h5ks5rzELUgaJpZM4NFv72 .
The mechanism is unrelated to OSCoAP or CoAP itself -- neither specifies how the operating system or library should communicate the identity of the requester to the application.
It is just part of the (current) API of aiocoap that the details of the requester are transported in the .remote property of the request message. That property is used both to convey the requester identity to the application and for the library to know where to send responses to.
(moved here from a different issue)