Status Stack Buffer Overrun

[lmarschall]

As i progress, using the Addon to establish an authorization workflow, i now stumbled across the following error:
"0xC0000409 - STATUS_STACK_BUFFER_OVERRUN".

Here's my request:

_cliendid = ["http://192.168.0.102:8000/api/user", "GET", [], true] call a3uf_common_fnc_addClient;

access_token = "7c9f8d58da05147b9cfe0bfb9210603668c924bc";

_token_string = format ["Bearer %1", access_token];

[_cliendid, [["Content-Type", "application/json"], ["Authorization", _token_string]]] call a3uf_common_fnc_setClientHeaders;

_response = [_cliendid] call a3uf_common_fnc_clientRequest;

Its a function, spawned by user input, which calls a local api endpoint, maybe its just a headers problem.

Thanks in advance,

Luke

[pixlcrashr]

I'll have a look into it. That seems like an error referring to the library, though.

[pixlcrashr]

this may be the cause: https://github.com/playnet-public/ArmA3URLFetch/blob/master/src/clients.cpp#L62

Later on I'll provide a library that you can test for that error.

[lmarschall]

Ok i think i can specify the error, it seems like no header was added to the request.

[pixlcrashr]

Ok i think i can specify the error, it seems like no header was added to the request.

Is it being added when using a normal request without any client? You may check this by calling http://httpbin.org/get.

[lmarschall]

can you set headers without a client session?

[lmarschall]

so i figured it out now!

it was indeed a headers problem, my request didnt work with the given headers array.
Here's my functional request with working headers:

_cliendid = ["http://192.168.0.102:8000/api/user", "GET", [], true] call a3uf_common_fnc_addClient;

_auth_string = format ["Authorization: Bearer %1", access_token];

[_cliendid, ["Content-Type: application/json", _auth_string]] call a3uf_common_fnc_setClientHeaders;

_response = [_cliendid] call a3uf_common_fnc_clientRequest;

So the original error was only the result of my api endpoint didnt know what to do with the given request and returning an error.

[pixlcrashr]

@lmarschall Good job! I may update the Wiki description, though.

Btw. it is therefore possible to append headers to a normal request (was missing in the docs). The parameters are as follows:

params [
	["_url", "", [""]],
	["_method", "", [""]],
	["_headers", [], [[]]],
	["_postData", "", ["", []]],
	["_decodeJson", false, [false]]
];

.

Indeed, the current Wiki description does not inlcude the _headers param.

[lmarschall]

maybe one addition, when the api endpoint sends a 400 status code, bad request, the addon crashes the game with the original error from above, maybe there's a way to handle such errors in the addon, so the game is not influenced by such bad requests.

[pixlcrashr]

maybe one addition, when the api endpoint sends a 400 status code, bad request, the addon crashes the game with the original error from above, maybe there's a way to handle such errors in the addon, so the game is not influenced by such bad requests.

I'll check it out.

[lmarschall]

so i created a framework for accessing player information in multiplayer missions from an api endpoint with your addon as work horse, would be interesting to get your feedback if that's a good idea over all: https://forums.bohemia.net/forums/topic/231816-accessing-player-data-from-api-endpoint/

Best Regards,

Luke

[pixlcrashr]

@lmarschall Don't mind me as I will not answer to any BI thread whatsoever anymore. Since I had an itigation with parts of the A3 community and BI, I avoid A3 forums and social media in general (aswell as not playing A3 that intense anymore).

---

But concerning your idea: Yes, ofc it would be possible and it is probably more easy to achieve than using extDB or some sort of.

One essential pitfall: In your current setup, everyone can access the data of every player by just modifying the player uid. Especially in the case of external "attacks". It is just very simple to launch fake attacks against such an endpoint. So the first thing to do would be to implement some sort of authentication (not authorization!!!, which is what you are doing currently in your model). Authentication therefore means that you have to somehow proof that the user requesting the endpoint is actually the user that should be allowed to request the data (e.g. simple example: username/password fields or redirects).

Also, how do you consider handling setters for profile data? Who should be allowed to set data on the player information and how should this be possible without allowing fake-servers or fake-players to modify the data on their own?

It is big topic, tbh. And there is possible more to it than I wrote for now. Just keep in mind that any HTTP endpoint can be misused, if any player (in ArmA 3) can access that HTTP server and its critical data.

[pixlcrashr]

@lmarschall Oh, and one thing that I have to mention: Why do you consider to rebuild and oauth like workflow?

First things first: OAuth2 is a workflow to authorize third party services to execute actions "as an specific identity" (e.g. the player grants the server to get and set the data for that specific player) - which would be a good choice for your idea later on.

Second: The workflow you want to use is the OIDC (Open ID Connect) workflow, which provides authentication of a player - which, as stated above already, is necessary as you otherwise are not able to tell if the accessing user is the expected or not expected user.

In summary, just use the existing workflows for such a thing (it should be no problem to implement the OIDC (and on top of that OAuth2) workflow). Ofc, there are other ways to implement a standarized workflow for authentication and authorization (e.g. Shibboleth SSO or SAML (which is OIDC compatible)).

[lmarschall]

@TheMysteriousVincent thank you so much for taking the time to give me some feedback, i really appreciate your concerns. At the moment it's just a experimental framework, but i will consider your answers, for further development.