Providing non NULL argument insufficient to restrict binding to specific address about ulfius HOT 8 CLOSED

I found two problems on my end. First my initialization of the sockaddr_in structure was faulty, and second, some operational issue with the java-based communication partner is throwing sporadic HTML 500 statuses - Neither of which appear to be related to your code or microhttpd as far as I can confirm - so I am closing the issue.

What remains true is that the problem ONLY occur when I specify a non-NULL bind_address to the ulfius_init_instance() function as noted above.

When I resolve it I will post the solution here for the benefit of other developers who may experience similar symptomology.

from ulfius.

Hello @continuum-embue , thanks for reporting the issue.

Indeed I didn't specify in the documentation that when you set the parameter bind_address when calling the function ulfius_init_instance, MHD, therefore Ulfius will use the port parameter specified in the bind_address parameter. I will update the documentation.

But as far as I could see, the bind_address parameter works as expected, because only clients with the IP address specified can connect to the endpoint. I have tested it with IPV4 addresses though, but I don't see why it would work differently with IPV6.

Can you provide a minimal code to reproduce your problem?

from ulfius.

Thank-you for responding. This point is not whether a client can connect - it's whether the server is listening on all interfaces, or only the one which is associated with the specified IP address. I'm attempting to limit ulfius-based API instance to a single interface. In my testing changing the bind_address to anything but NULL in ulfius_init_instance() resulted in the subsequent ulfius_start_framework() call failing - and I am using IPv4 structures and addresses.

I will generate some minimal code to reproduce the issue.

from ulfius.

I didn't mean to close the issue.

from ulfius.

When I tested your issue, I modified the simple_example.c like this:

int main (int argc, char **argv) {
  int ret;
  
  // Set the framework port number
  struct _u_instance instance;
  
  struct sockaddr_in name;
  name.sin_family = AF_INET;
  name.sin_port = htons(PORT);
  inet_aton("127.0.0.1", (struct in_addr *)&name.sin_addr.s_addr);
  
  y_init_logs("simple_example", Y_LOG_MODE_CONSOLE, Y_LOG_LEVEL_DEBUG, NULL, "Starting simple_example");
  
  if (ulfius_init_instance(&instance, PORT, &name, NULL) != U_OK) {
    y_log_message(Y_LOG_LEVEL_ERROR, "Error ulfius_init_instance, abort");
    return(1);
  }

And then only localhost was able to connect to the address http://host:8537/

from ulfius.

@continuum-embue , any update on this issue?

from ulfius.

Sorry for the delay. I've been trying to get some unrelated production code out the door.

Your response "And then only localhost was able to connect to the address http://host:8537/" is nonsensical. The point of specifying the address (in_addr *) argument, ostensibly, is to restrict which interfaces the ulfius (microhttpd) server runs on - not which client IPs can connect to it - although, arguably, both constraints can be simultaneously true. Also, in my initial report. I noted it's not the ulfius_init_instance() call that fails - it's the follow-up ulfius_start_framework() call - which makes no sense at all.

Let me see if I can find the code that originally failed and get back to you.

from ulfius.

Sorry, I was a little confused.
Ulfius' bind_address is directly binded to MHD's MHD_OPTION_SOCK_ADDR, and MHD's documentation says that:

MHD_OPTION_SOCK_ADDR

Bind daemon to the supplied socket address. This option should be followed by a struct sockaddr . If MHD_USE_IPv6 is specified, the struct sockaddr should point to a struct sockaddr_in6, otherwise to a struct sockaddr_in. If this option is not specified, the daemon will listen to incoming connections from anywhere. If you use this option, the ’port’ argument from MHD_start_daemon is ignored and the port from the given struct sockaddr * will be used instead.

If I update the simple_example as above, then simple_example binds to the loopback interface, and http requests from other interfaces will fail. That's how I understood this option in the first place, but maybe I've missed something?

from ulfius.