diff --git a/lib/libwebsockets.c b/lib/libwebsockets.c index 860dee88..43ede68f 100644 --- a/lib/libwebsockets.c +++ b/lib/libwebsockets.c @@ -654,7 +654,17 @@ lws_get_addresses(struct lws_context *context, void *ads, char *name, #endif } -const char * +/** + * lws_get_peer_simple() - Get client address information without RDNS + * @wsi: Local struct lws associated with + * @name: Buffer to take client address name + * @name_len: Length of client address name buffer + * + * This provides a 123.123.123.123 type IP address in @name from the + * peer that has connected to @wsi + */ + +LWS_VISIBLE const char * lws_get_peer_simple(struct lws *wsi, char *name, int namelen) { #if LWS_POSIX diff --git a/lib/libwebsockets.h b/lib/libwebsockets.h index 21debc13..f2f9fc90 100644 --- a/lib/libwebsockets.h +++ b/lib/libwebsockets.h @@ -1987,6 +1987,9 @@ LWS_VISIBLE LWS_EXTERN void lws_get_peer_addresses(struct lws *wsi, lws_sockfd_type fd, char *name, int name_len, char *rip, int rip_len); +LWS_VISIBLE LWS_EXTERN const char * +lws_get_peer_simple(struct lws *wsi, char *name, int namelen); + LWS_VISIBLE LWS_EXTERN int lws_get_random(struct lws_context *context, void *buf, int len); diff --git a/lib/private-libwebsockets.h b/lib/private-libwebsockets.h index ab06b9d4..8450c43c 100644 --- a/lib/private-libwebsockets.h +++ b/lib/private-libwebsockets.h @@ -1722,9 +1722,6 @@ LWS_EXTERN int lws_get_addresses(struct lws_context *context, void *ads, char *name, int name_len, char *rip, int rip_len); -LWS_EXTERN const char * -lws_get_peer_simple(struct lws *wsi, char *name, int namelen); - #ifdef LWS_WITH_ACCESS_LOG LWS_EXTERN int lws_access_log(struct lws *wsi); diff --git a/libwebsockets-api-doc.html b/libwebsockets-api-doc.html index 80ccd376..504f4f55 100644 --- a/libwebsockets-api-doc.html +++ b/libwebsockets-api-doc.html @@ -166,6 +166,40 @@ representing the library version followed by the git head hash it was built from
+You only need to call this if you plan on using SSL client connections on +the vhost. For non-SSL client connections, it's not necessary to call this. +++The following members of info are used during the call +
+- options must have LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT set, +otherwise the call does nothing +- provided_client_ssl_ctx must be NULL to get a generated client +ssl context, otherwise you can pass a prepared one in by setting it +- ssl_cipher_list may be NULL or set to the client valid cipher list +- ssl_ca_filepath may be NULL or client cert filepath +- ssl_cert_filepath may be NULL or client cert filepath +- ssl_private_key_filepath may be NULL or client cert private key +
+You must create your vhost explicitly if you want to use this, so you have +a pointer to the vhost. Create the context first with the option flag +LWS_SERVER_OPTION_EXPLICIT_VHOSTS and then call lws_create_vhost with +the same info struct. +
+Prepares your context struct for use with lejp ++
+lejp does not perform any allocations, but since your user code might, this +provides a one-time LEJPCB_DESTRUCTED callback at destruction time where +you can clean up in your callback. ++
+This tells the old callback it was destroyed, in case you want to take any +action because that callback "lost focus", then changes to the new +callback and tells it first that it was constructed, and then started. +++Changing callback is a cheap and powerful trick to split out handlers +according to information earlier in the parse. For example you may have +a JSON pair "schema" whose value defines what can be expected for the rest +of the JSON. Rather than having one huge callback for all cases, you can +have an initial one looking for "schema" which then calls +lejp_change_callback to a handler specific for the schema. +
+Notice that afterwards, you need to construct the context again anyway to +parse another JSON object, and the callback is reset then to the main, +schema-interpreting one. The construction action is very lightweight. +
+Because lejp is a stream parser, it incrementally parses as new data +becomes available, maintaining all state in the context struct. So an +incomplete JSON is a normal situation, getting you a LEJP_CONTINUE +return, signalling there's no error but to call again with more data when +it comes to complete the parsing. Successful parsing completes with a +0 or positive integer indicating how much of the last input buffer was +unused. ++
+This provides a 123.123.123.123 type IP address in name from the +peer that has connected to wsi ++