[BUG?] 409's when issuing API commands

[Aibohphobia]

As outlined in this post, there is a problem with issuing API commands (with a valid X-Autologin and X-Pin supplied to the server) after a nation is logged in manually (through a browser). Private shards continue working, but issuing commands results in the following message:

Previous Login Too Recent

You attempted to log in with a nation that already logged in successfully a few seconds earlier. This may mean that you are attempting to maintain a connection via password or autologin rather than supplying a PIN.

Error: 409 Conflict

Code: Select all

!DOCTYPE html>
<h1 style="color:red">Previous Login Too Recent</h1>
<p>You attempted to log in with a nation that already logged in successfully a few seconds earlier. This may mean that you are attempting to maintain a connection via password or autologin rather than supplying a PIN.
<p style="font-size:small">Error: 409 Conflict
<p><a href="/pages/api.html">The NationStates API Documentation</a>

The message is not in XML format like other API responses, and it helps very little in identifying the problem. It stays the same even if you wait for more than 1 hour after the manual login, not just "a few seconds". The X-Pin field is supplied, so the part about it missing is false as well. Is this behaviour intended?

The API is not clear as to how parameters are supposed to be passed to the server either. From personal observation, it has to be through a POST request as opposed to GET, but it is not clearly stated in the documentation.

[Trotterdam]

Private shards continue working, but issuing commands results in the following message:

Huh. Does it work that way even if your script does not attempt to perform a command immediately after performing a shard, or tries to perform several shards in a row before then performing a command?

(I mean, "check what issue the nation has, then answer it" is a perfectly logical program flow, but always doing things in that order can obscure where the problem actually lies.)

The message is not in XML format like other API responses, and it helps very little in identifying the problem.

Like I said in the other thread, you shouldn't be looking at this. It's meant to be human-readable, not machine-readable.

Instead, retrieve

Code: Select all

curl_getinfo($query, CURLINFO_RESPONSE_CODE)

which should give a simple 409.

It stays the same even if you wait for more than 1 hour after the manual login, not just "a few seconds". The X-Pin field is supplied, so the part about it missing is false as well. Is this behaviour intended?

Odd. The X-Pin is supposed to be invalidated if you make any manual login at all, even 1 hour ago (and similarly, it's also invalidated if you just wait 2 hours), but that should give a 403 error, not 409.

Are you sure your browser isn't auto-refreshing or anything of that sort? Also check if you have NationStates open on other devices like mobile phones.

Would you mind sharing your code? (Censoring out any personal information, of course.) Pretty hard to pinpoint the problem from just a three-digit number.

[Aibohphobia]

Huh. Does it work that way even if your script does not attempt to perform a command immediately after performing a shard, or tries to perform several shards in a row before then performing a command?

(I mean, "check what issue the nation has, then answer it" is a perfectly logical program flow, but always doing things in that order can obscure where the problem actually lies.)

Yes, it does. Both if it doesn't attempt a command and if several private and/or public shards are performed in a row.

Odd. The X-Pin is supposed to be invalidated if you make any manual login at all, even 1 hour ago (and similarly, it's also invalidated if you just wait 2 hours), but that should give a 403 error, not 409.

Are you sure your browser isn't auto-refreshing or anything of that sort? Also check if you have NationStates open on other devices like mobile phones.

Would you mind sharing your code? (Censoring out any personal information, of course.) Pretty hard to pinpoint the problem from just a three-digit number.

Precisely! The reason for that, it seems, is X-Autologin. If I take it out of the query, the private shards stop working. Which proves your point that X-Pin is invalidated upon every new login. It also means that a valid X-Pin is required for API commands, which the documentation does not mention at all.

Thank you. The script is run on the server from a crontab, not inside of a browser. The nation in question does not have any active sessions on other devices.

I agree. I'll send you the link in a telegram. Thank you very much for your help.
I think I'll be able to fix it myself, because I understand the issue now, but I'll appreciate you taking a look as well.

[Trotterdam]

It also means that a valid X-Pin is required for API commands, which the documentation does not mention at all.

This is definitely not the case. When I tested the API command with wget a short time ago, I supplied only an X-Password, with neither X-Autologin nor X-Pin. It worked.

I agree. I'll send you the link in a telegram. Thank you very much for your help.

I thought you preferred forum posts over telegrams? Is this code top-secret?

Anyway, I can't guarantee this will help, but some things to take note of:

• Most importantly, modify your getPage() function with roughly the code at the end of this post in order to obtain up-to-date X-Pins. Do not hardcode your X-Pin.
• You may want to introduce some sort of ratelimiter. While answering issues on only one nation shouldn't cause problems (you can only have a maximum of 5 issues at any time, retrieving plus answering them means 6 API requests total, well under the 50 request maximum that's allowed in one burst), if you're running this script for a lot of nations you could end up in trouble.
• Obviously not going to come up much, but you may want to add proper code for dealing with issue #407, which has zero options.
• Take a look at what I pointed out to SherpDaWerp about the two different ways cURL can handle POST data. I'm still not sure if the server can handle multipart/form-data format or not (wget does not support multipart/form-data, so I can't easily test it - it seems that Qt does support it, but that would require writing an actual program to test it which is considerably more hassle), but if the code doesn't work as is, it's worth trying to see if it helps. (Though if you have ever gotten a private command to work with the current code, I guess this can't be it.)
• There's some code that just seems superfluous, like the "Accept-Language" header (NationStates only comes in one language?). It's probably harmless, but why risk it?
• Don't forget to always check for both a cURL error and a bad HTTP status code (in that order). It looks like you're not performing any error-checking at all on your c=issue commands, only on your initial q=issues+unread request?
• I'm not familiar with PHP. What does putting an "@" before a function call do? I'm seeing it in several examples on the official site, but I can't find any documentation on what it means.

[Aibohphobia]

When I tested the API command with wget a short time ago, I supplied only an X-Password, with neither X-Autologin nor X-Pin. It worked.

X-Password always works. I meant that private shards can be accessed through X-Autologin alone, whereas private commands require an X-Pin (in lieu of an X-Password). Therefore, I do not see a point to accessing the API through anything other than X-Password. It happens over HTTPS anyway.

I thought you preferred forum posts over telegrams? Is this code top-secret?

I preferred forum posts for that specific script, because I made it with the intention for other people to use it too and needed feedback, whereas the PHP bot has always been intended for personal use only. I am not a huge fan of sharing incomplete/dysfunctional code either.

You may want to introduce some sort of ratelimiter.

Thank you. I will if I ever decide to re-write the script to interface multiple nations.

Obviously not going to come up much, but you may want to add proper code for dealing with issue #407, which has zero options.

That's great advice, especially if they put another issue chain into the game! Thank you, I completely forgot about this.

I'm still not sure if the server can handle multipart/form-data format or not (wget does not support multipart/form-data

It can.

It's probably harmless, but why risk it?

Risk what exactly? That code is just left-overs from when I was scraping pages without the API. It is indeed superfluous now that I do not have to emulate a browser.

Don't forget to always check for both a cURL error and a bad HTTP status code (in that order). It looks like you're not performing any error-checking at all on your c=issue commands, only on your initial q=issues+unread request?

You are right, I am very lazy when it comes to error-handling. Usually, if the code works, it works. If it fails once, that means the server is down, which will be "fixed" the next time the cron job is run anyway. I don't really see an advantage to continuously running an error-checking loop with delays.

I'm not familiar with PHP. What does putting an "@" before a function call do?

It's an error-suppression operator.