Add a Filter for API endpoints

[namithj]

I have checked the following:

• I've searched existing issues and found nothing related to my issue.

Describe the feature you want to add

For the purpose of AE we require that the Hosts selection be filterable. (This is for adding a API Host option next to the keyword search option in AE so that can be federated in principle)

A filter for the specific settings property will fine for our use case, but we also need to consider the security aspects of allowing such a filter.

Perhaps limit the values to the endpoints defined on hosts.json as s second level of security.

Mockups or Images of the feature

NA

[costdev]

If this option triggers an AJAX request which returns the selected host's data, couldn't the AJAX callback just do define( 'AP_HOST', wp_unslash( $_POST['selected_host'] ) );?

[namithj]

The idea is to change the chosen host in AE so that users can search in different repositories.

For this to work I need to dynamically change the set host in AU.

[costdev]

Ah, so the chosen host won't be submitted via AJAX?

(For clarity on my earlier comment: Regarding the dynamic part, that's why I was asking about AJAX, as the define( 'AP_HOST', ... ) would only apply to that request, and wouldn't be a permanent constant definition)

[namithj]

It's would be a normal POST. The change needs to apply to AU so that the rewriting happens for that host and not the one set in settings, hence the filter.

Eg : The admin might have set AC as the host in plugin settings but a user might want to search w.org repo for plugins in AE. So AU needs to switch from AC to w.org for just that search and nothing else.

[namithj]

Benefit of a filter would be, I can set it just before the search and remove it after so that it doesn't affect or interfere with any other scheduled update checks which might happen during one of the other actions.

[costdev]

Yep gotcha. I just wanted to check what was achievable without introducing the filter which effectively adds a third way to select the host. In an AJAX request, scheduled update checks wouldn't run, but since this is a normal POST request, they would.

---

While a filter makes sense in AE's use case, even if we lock the filter down, I'm still uncomfortable with a plugin being able to change the API host that the user/host chose. I'm thinking about plugins being able to change the host back to dotorg, etc.

[namithj]

That's my dilemma too. Need to figure out a solution without having to reinvent AU inside of AE. Need to offer AC, FAIR, W.org (any other prominent repos which might come up) inside of AE.

[costdev]

Totally. A filter is by far the easiest way to achieve the use case, it's just that problem of other plugins being able to do so as well.

I'll have a think as well and see if I can come up with any potential alternatives to introducing a filter. Happy to discuss and test any other ideas you have too. I think if we can't come up with something else in a reasonable time, we can look at the filter again. Does that work for you?

[namithj]

Yeah, so far my idea is to introduce a filter but then validate it so that the filtered value is one that's in the hosts.json as well.

[toderash]

This is making sense, but I think I'd add a validation step to ping the supplied node url and make sure it properly supports the API. Later when a list of federated nodes becomes available, we'll also be able to check against it and probably warn (not block) that the node is not federated.