Misconfigured f-API can create infinite request loop

[surchs]

If I

• deploy a f-API and
• accidentally set https://neurobagel.org/config/#local_nb_nodesjson to my own f-API address

Then: I can create an infinite loop because once I send a query to my f-API, it will then send a query of its own to any APIs listed in local_nb_nodes.json - including itself. Because the f-API endpoints are so similar to the n-API endpoints, this will actually be a valid query request, thus starting another federated query and so on.

We should:

• Confirm that this happens every time I set my own f-API in the local_nb_nodes.json and then write a test to make sure we prevent a loop from happening in this case
• Add some basic check that lets and f-API realize when it is talking to itself

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 75 days.
We have applied the _flag:stale label to indicate that this issue should be reviewed again.
When you review, please reread the spec and then apply one of these three options:

• prioritize: apply the flag:schedule label to suggest moving this issue into the backlog now
• close: if the issue is no longer relevant, explain why (give others a chance to reply) and then close.
• archive: sometimes an issue has important information or ideas but we won't work on it soon. In this case
  apply the someday label to show that this won't be prioritized. The stalebot will ignore issues with this
  label in the future. Use sparingly!

[alyssadai]

After further investigation into this issue, I think this will actually require more effort to resolve than it's probably worth.

The problem is that the only port exposed to the f-API is NB_API_PORT, which is the port used by the service inside the container. To catch when local_nb_nodes.json has been misconfigured to point at the f-API, the service would need to know about NB_API_PORT_HOST, which is not an environment variable inside the container - it's only used by the docker-compose.yml file itself.

To catch misconfigurations, we would probably need to expose NB_API_PORT_HOST as an environment variable to the f-API container, and then also ensure that the f-API reads it in - all just for the purposes of emitting a warning message.

Instead, maybe we could try to prevent these issues by updating our docs with a warning about the ports.

[surchs]

We can also attach some unique identifier for the node making the request as part of the request. Then the solution would be more generic:

• I received a request from a node with my own identifier -> I must be talking to myself. Better stop
• I received a query request that includes a node identifier (that is also in my local_nodes list) -> there is a loop here. Better stop

But I agree with you @alyssadai, that's more involved and not for now. Maybe a good time to look at this again would be when we address auth - because each node will have a unique client_id as part of that, and we could reuse the client_id for this purpose.

[alyssadai]

Thanks @surchs.

To clarify, the ideal solution would be generic enough to detect a request coming from any f-API, regardless of whether or not the f-API is part of the same stack as the recipient f-API, to avoid unpredictable behaviours.

That said, I guess the infinite request loop would only happen if an f-API is actually pointing to itself.