XF 2.1 Unexpected API response

[Assadi]

I am trying to use the API to handle authentication for a video game, but it's been a little annoying to say the least. Initially, I created a super admin API key with all scopes granted. One would expect this to allow you to perform all actions, however, that is not the case.

With a super admin key, I can authenticate users via the auth/ endpoint, but I cannot create users via the users/ endpoint. Instead, you have to use a key associated with an admin user. Using an admin key does not grant you access to the endpoint require for authentication, though. This is not a big deal; I can just use two keys. The real annoyance arises with the fact that a super admin key simply doesn't have access to half of the fields in the user object (e.g., user state, group ids, and so on) — only my standard admin user key receives the expected contents of the user object.

I am not sure what we are expected to do currently. It seems the only way to get around this is to first authenticate the user with the super admin key, then, ignore the user object that is returned and instead make a separate request to the API with a separate key in order to retrieve the necessary data.

Is this a bug with super admin key privileges or is this actually the intended functionality and I'm maybe just missing something?

 

[Mike]

This might be a bit of a terminology thing, but it's a super user key rather than a super admin key. The reason I emphasize this is because this is a key that can authenticate as any user, but you are always in the context of a particular user (which may not be an admin) and, by default, you'll be constrained to the permissions that apply to that user (and to the allowed scopes, if relevant).

If you're not passing a user along in the XF-Api-User header with a super user key, then the context will be that of a guest and thus by default, you'll only have access to things that a guest can access. This would mean that they can't create users and can't access administrator only data.

So one option is to pass the user ID along of a user that can do those things.

However, if you're using a super user key, you can opt into bypassing permissions entirely by passing along a api_bypass_permissions parameter with any request (a value of 1 is fine). This would mean that a guest user could create a new user and this will also bypass various permission constraints on the type of information returned from a user. (The allowed API scopes would generally be the limit of what you can access.)

 

[Mike]

There is a bug report relating to what is returned by the auth endpoint (which gets into things like entity verbosity, but I'll get into that there): https://xenforo.com/community/threa...rom-user-response-in-auth-api-request.160147/

 

[Assadi]

@Mike Thanks a ton! Possibly worth adding some of that to the documentation; not super obvious without digging around in the code

 

[fahad ashraf]

@Mike i made a api try to use api key with following url mysite.com/api/ex-category?api_bypass_permissions=1 but i am getting error

{
    "errors": [
        {
            "code": "no_api_key_in_request",
            "message": "No API key was included in the request.",
            "params": []
        }
    ]
}