XF 2.2 Issue with the API endpoints

[Jackie13]

Hi there,

We are trying to build an SSO integration with a third-party app and we are facing some issues with the XenForo API.

When we are sending POST requests to the '/users/' endpoint to create a new user, instead of creating the user and returning the user data. We get a response that has a bunch of user objects that are not related to the one we are trying to create. And also the user is not created.

Also when we are trying to send a request to '/auth/login-token' we get an error that says that the endpoint does not exist.

Do you have any existing solutions to this issue? Or do you need any complimentary information to be able to diagnose what's going on here?

Thanks!

 

[Jackie13]

Hi there,

A quick follow on this thread.

Is there anyone checking these issues from the XenForo team? On the support email, we were told that these issues need to be handled on the forums and not there.

Here are some screenshots of the responses we receive:
https://share.getcloudapp.com/xQuzWOon
https://share.getcloudapp.com/E0uobRee

Thanks!

 

[XFA]

You posted on the wrong forum this forum is related to development discussions.
There is a dedicated bug report forum.

 

[kolakube]

My best guess is to check the 1) API key is set as a super user 2) you are on the latest version of 2.2.x 3) no other addon is manipulating your API return. I use the auth:login-token in my app without issues.

 

[Jackie13]

You posted on the wrong forum this forum is related to development discussions.
There is a dedicated bug report forum.

Thanks, I'll repost in the bug report forum. It just sounded better to me to post here since this is a development issue.

My best guess is to check the 1) API key is set as a super user 2) you are on the latest version of 2.2.x 3) no other addon is manipulating your API return. I use the auth:login-token in my app without issues.

Thanks for your time, we've marked those points already. They are all as they are supposed to be.

 

[Chris D]

You were correct the first time, but no big deal

While I don't think this accounts entirely for the issue you're running into, it's worth noting that these API requests are not formed correctly.

As per the API documentation here the request bodies should be sent using application/x-www-form-urlencoded encoding, rather than JSON.

It is worth correcting that in your API client in the first instance but note that in this screenshot the error reason is invalid_method and it goes on to suggest the only supported methods are POST.

The UI of your API client seems to imply that you're trying to send a POST request but that doesn't seem to be what they're sending. I have no experience with the Insomnia client, but something with it doesn't seem quite correct here.

If it's of any use, I've been using Advanced REST Client which is free and open source and doesn't appear to have issues sending POST requests.

 

[Jackie13]

You were correct the first time, but no big deal

While I don't think this accounts entirely for the issue you're running into, it's worth noting that these API requests are not formed correctly.

As per the API documentation here the request bodies should be sent using application/x-www-form-urlencoded encoding, rather than JSON.

It is worth correcting that in your API client in the first instance but note that in this screenshot the error reason is invalid_method and it goes on to suggest the only supported methods are POST.

The UI of your API client seems to imply that you're trying to send a POST request but that doesn't seem to be what they're sending. I have no experience with the Insomnia client, but something with it doesn't seem quite correct here.

If it's of any use, I've been using Advanced REST Client which is free and open source and doesn't appear to have issues sending POST requests.

Thanks, Chirs!

We changed the encoding and that made the auth-token request to work. So that was great!

As for the user creation, we change the encoding for that too but we get the same result as before so basically, instead of creating a user the system, is returning a bunch of users that have no connection to the one I'm trying to create.

I tried using the app you have mentioned but it is very buggy on my system (I'm using the latest MacOS version) and it doesn't even send the requests I'm trying to send.

Insomnia is definitely sending proper POST requests, we've been using it for a lot of other development projects.

Now I'm thinking that perhaps your API is returning those values when I'm trying to create a user because I may not pass all the required parameters. From the API Documentation I'm not sure which of the fields are mandatory.

Do you have a list of mandatory fields for the POST '/users' endpoint?

Thanks a lot for your time!

 

[Chris D]

Insomnia is definitely sending proper POST requests

I may have to try it myself, but I'm not convinced that this is the case.

Now I'm thinking that perhaps your API is returning those values when I'm trying to create a user because I may not pass all the required parameters.

The only logical reason I can think of for it returning a list of users is if the request is being sent as GET rather than POST. A GET request to the endpoint in question returns a list of users, which appears to be what is happening.

That would also be consistent with the error message in the first example that wasn't working with the invalid_method error.

In my testing with the aforementioned REST client, I was just able to create a test user with the same values you mentioned previously, obviously as form-encoded rather than JSON. I did get an error, saying it was missing the password. Which I added, but once I did I got a 200 response with success: true and the new user's details.

In all cases if particular input is required and it is not documented, you will be notified via an error response.

 

[Chris D]

To be fair, I have seen for myself now that Insomnia works fine, but I'm not sure if that just makes it even more confusing that it doesn't work for you



I'm going to have to see if I can break it in a similar way to figure out what is going on!

 

[Chris D]

Unfortunately I'm not getting very far by way of explaining what you've run into here. All I can say is that I cannot reproduce it in either of the clients I've tried.

If we take your initial auth-token example, and passing in JSON instead of form encoding:



I do not get any errors about an invalid method. I actually get the expected error in this case which is that the required input is missing (this makes sense because we require form encoding).

If I switched that to GET however...

It is only then that I get the same error you did:



If I fix this and change it back to POST and form encoding it of course works:



As before in my last post, creating a user works. I can only reproduce the same results as you if I change the request method to GET where I get a list of users:



I'm at a complete loss as to how you are seemingly sending out GET requests despite the UI showing POST but, as I say I really can't reproduce that.

It's also not something I recall us coming across before either so I'm sorry I'm not being much help here.

The last debugging step I can think of to remove XF out of the equation entirely is to add a PHP file to the root of your web server with the following contents:

<?php

header('Content-Type: application/json; charset=utf-8');

echo json_encode([
   'method' => $_SERVER['REQUEST_METHOD']
]);

And then make requests to the URL of that script with different methods where the Preview pane should list the method you have chosen.






If this does work as expected please submit a ticket for my attention from your customer area. I'll ideally need access to your Admin control panel, and access to modify files on your server so I can do some further debugging and hopefully get to the bottom of this for you.

 

[Jackie13]

Unfortunately I'm not getting very far by way of explaining what you've run into here. All I can say is that I cannot reproduce it in either of the clients I've tried.

If we take your initial auth-token example, and passing in JSON instead of form encoding:

View attachment 263268

I do not get any errors about an invalid method. I actually get the expected error in this case which is that the required input is missing (this makes sense because we require form encoding).

If I switched that to GET however...

It is only then that I get the same error you did:

View attachment 263269

If I fix this and change it back to POST and form encoding it of course works:

View attachment 263270

As before in my last post, creating a user works. I can only reproduce the same results as you if I change the request method to GET where I get a list of users:

View attachment 263272

I'm at a complete loss as to how you are seemingly sending out GET requests despite the UI showing POST but, as I say I really can't reproduce that.

It's also not something I recall us coming across before either so I'm sorry I'm not being much help here.

The last debugging step I can think of to remove XF out of the equation entirely is to add a PHP file to the root of your web server with the following contents:

<?php

header('Content-Type: application/json; charset=utf-8');

echo json_encode([
   'method' => $_SERVER['REQUEST_METHOD']
]);

And then make requests to the URL of that script with different methods where the Preview pane should list the method you have chosen.

View attachment 263274


View attachment 263275

If this does work as expected please submit a ticket for my attention from your customer area. I'll ideally need access to your Admin control panel, and access to modify files on your server so I can do some further debugging and hopefully get to the bottom of this for you.

Thanks a lot for your time Chris!

In Insomnia if you press on the 'Timeline' tab on the response side you'll be able to see something that looks like a cURL log. In the log it says that it actually sent a POST request. So the request type is definitely the correct one.

Here is a screenshot with the timeline where I sent both a GET and a POST request to the endpoint with the same data so that you can see the differences:


I'm thinking that there might be a setup difference on our end that causes the issue so I"m going to submit a ticket where I'll request to be assigned to you and in there I'll give you whatever access credentials you need to be able to diagnose the issue further.

 

[Chris D]

@Jackie13 thank you for sharing the logs this is actually very helpful and reveals the underlying issue.

Note: I have removed the screenshot as it contained sensitive information.

This is the crux of the issue:





You are sending requests to http:// rather than https://. These requests are then being redirected:



Insomnia isn't handling the redirect in a way I'd necessarily expect but I'm not 100% sure. After the redirect, rather than re-performing the POST request to the updated https:// version of the URL, it is actually switching to GET:



This entirely explains the behaviour you're seeing.

When making API requests, always include the correct URL scheme rather than http:// or omitting it entirely. In your case, requests should be made to https://members.brandgrowthexperts.com/api/users/ to ensure they're not redirected to a GET request.

 

[Jackie13]

@Jackie13 thank you for sharing the logs this is actually very helpful and reveals the underlying issue.

Note: I have removed the screenshot as it contained sensitive information.

This is the crux of the issue:


View attachment 263306


You are sending requests to http:// rather than https://. These requests are then being redirected:

View attachment 263307

Insomnia isn't handling the redirect in a way I'd necessarily expect but I'm not 100% sure. After the redirect, rather than re-performing the POST request to the updated https:// version of the URL, it is actually switching to GET:

View attachment 263308

This entirely explains the behaviour you're seeing.

When making API requests, always include the correct URL scheme rather than http:// or omitting it entirely. In your case, requests should be made to https://members.brandgrowthexperts.com/api/users/ to ensure they're not redirected to a GET request.

Thank you very much for your help, Chris! That worked!

PS: I regenerated the API Key after the screenshots so we were good on that with the screenshot

Thank you again for your time! That fixed our issue!