Advertisement
by Bluelight-R006 » Thu Jun 20, 2019 10:33 pm
by Frisbeeteria » Thu Jun 20, 2019 10:59 pm
by Bluelight-R006 » Thu Jun 20, 2019 11:00 pm
Frisbeeteria wrote:The API is a method by which your script can send telegrams. It is not a telegram sending script. It's just a portal, the front door if you will. If you don't have a telegram script of some sort, the API is useless to you.
Look around this thread and this forum. Several people offer public scripts.
by The Greater Low Countries » Sat Aug 03, 2019 9:16 am
by Frisbeeteria » Sat Aug 03, 2019 12:38 pm
The Greater Low Countries wrote:
- Can I share a client key between two nations?
- Can I own two client keys?
- Can I use API telegramming on as many nations as I want?
by The Greater Low Countries » Sat Aug 03, 2019 12:49 pm
Frisbeeteria wrote:The Greater Low Countries wrote:
- Can I share a client key between two nations?
- Can I own two client keys?
- Can I use API telegramming on as many nations as I want?
- Client keys are region specific, so you'll only be able to use it to recruit for the region that applied for it. Can two people from the same region use a single key to recruit? Yes, but there is no benefit if they both run simultaneously. The API rate limit will still apply. The net impact is that one of the recruiters will send most or all of their telegrams, and the other will have most or all of his bounce. We'd greatly prefer than you not do this, as even bouncing the message uses resources unnecessarily.
If they take turns, then yes, it can be shared effectively.- Yes. You can own different keys for different regions. The nation applying needs to be a resident of the region in question, so it makes sense to have a resident puppet hold the key. As the player, you can have more than one key.
- Depends on how your script works. If it's a browser-based script, then the session_ID will kick off all but the latest nation. I honestly don't know whether their are other methods that allow simultaneous scripting on a single computer. Different nations on different computers can certainly run simultaneously.
by Aibohphobia » Sun Aug 11, 2019 8:14 pm
by Trotterdam » Sun Aug 11, 2019 9:06 pm
On your main nation page, you will see text that goes along the lines of:
The Recursiveness of Aibohphobia is a gargantuan, efficient nation, ruled by Dark Inquisitor with an iron fist, and renowned for its avowedly heterosexual populace, irreverence towards religion, and devotion to social welfare. The hard-nosed, cynical, humorless population of 16.162 billion Aibohphobians are ruled without fear or favor by a psychotic dictator, who outlaws just about everything and refers to the populace as "my little playthings."The part that I underlined is what the "admirable" shard returns.
That clearly stands for "General Assembly vote". Unfortunately, there is no resolution currently at vote, so I can't easily test how it works. In any case, it should only ever return something interesting for nations that are in the World Assembly.
Average income as displayed on your nation page. The same value represented by census score 72, but actually with less accuracy, making it fairly redundant.
Appears to give the same value as q=census&mode=rrank. Similarly, wcensus gives the same value as q=census&mode=rank. Not sure why these exist, probably a holdover from an earlier version of the API that is now obsolete but kept for the benefit of older scripts that haven't been updated to use the new features.
The only difference is if the nation hasn't entered a custom field. Either due to not having unlocked it yet, or due to deliberately leaving it blank. In that case, "customleader" etc. will return a blank (to represent the lack of a custom entry), while "leader" etc. will return the default values used for the issue macros ("@@NAME@@ City", "Leader", "a major religion").Aibohphobia wrote:What is the difference between custom and non-custom tags, such as customleader and leader?
"demonym" is the adjective demonym ("Spanish", etc.), while "demonym2" is the noun demonym ("Spaniard", etc.), as distinguished on your settings page. On very many nations they will be identical, but they don't have to be,
by Aibohphobia » Mon Aug 12, 2019 7:26 am
First of all, thank you very much!Trotterdam wrote:Not sure why these exist, probably a holdover from an earlier version of the API that is now obsolete but kept for the benefit of older scripts that haven't been updated to use the new features.
Seems kind of pointless. I appreciate the detailed explanation.Trotterdam wrote:The only difference is if the nation hasn't entered a custom field. Either due to not having unlocked it yet, or due to deliberately leaving it blank. In that case, "customleader" etc. will return a blank (to represent the lack of a custom entry), while "leader" etc. will return the default values used for the issue macros ("@@NAME@@ City", "Leader", "a major religion").
Thank you once more for helping me and another fellow from my region - SherpDaWerp.Trotterdam wrote:"demonym" is the adjective demonym ("Spanish", etc.), while "demonym2" is the noun demonym ("Spaniard", etc.), as distinguished on your settings page. On very many nations they will be identical, but they don't have to be.
by Trotterdam » Mon Aug 12, 2019 9:01 am
Eh, I appreciate it. For my use case, it's more useful to know the macros as they actually appear in issues without needing to substitute blanks with default values myself, but I can see how other people might be interested in the difference between a nation that, say, hasn't named custom capital city versus one whose capital city name just happens to match the default (since several real-life nations actually do have capital cities of the "@@NAME@@ City" format). Note that the difference is visible on your nation page.Aibohphobia wrote:Seems kind of pointless. I appreciate the detailed explanation.Trotterdam wrote:The only difference is if the nation hasn't entered a custom field. Either due to not having unlocked it yet, or due to deliberately leaving it blank. In that case, "customleader" etc. will return a blank (to represent the lack of a custom entry), while "leader" etc. will return the default values used for the issue macros ("@@NAME@@ City", "Leader", "a major religion").
I tried it once a few days back and it worked for me, though I was using Wget, not cURL. (I don't use either one for my actual scripting these days, but this was just a single test request, not a script.)Aibohphobia wrote:Trotterdam wrote:P.S. The issue command seems completely dysfunctional. I've tried both GET and POST requests through cURL, and they do nothing. The URL's are properly formed, and XML is parsed without errors as well. I'll check omitting 'v=' from the query tomorrow as well as what response the server actually returns.
by The Northern Light » Mon Aug 12, 2019 2:01 pm
Imperium Anglorum wrote:Also, would it be possible to have an API query which tells us what kind of telegram is being sent? Something like:
- Code: Select all
https://www.nationstates.net/cgi-bin/api.cgi?a=infoTG&tgid=(TGID)&key=(Secret Key)
Returning information on the telegram itself, like the delivery data, by whom the telegram was blocked, and what kind of telegram is being sent (recruitment, campaign, unmarked).
Imperium Anglorum wrote:Bump.
Eluvatar wrote:Yes that's a good idea, but it's lower in my priorities than, say, improving update speed right now. Sorry.
Home of the WADP, Planet Eras, and the Constibillocode!
by Aibohphobia » Mon Aug 12, 2019 3:45 pm
My bot is a cron job that runs a PHP script. What do you normally use instead of cURL and wget?Trotterdam wrote:I tried it once a few days back and it worked for me, though I was using Wget, not cURL. (I don't use either one for my actual scripting these days, but this was just a single test request, not a script.)
by Trotterdam » Mon Aug 12, 2019 4:31 pm
This, actually.Aibohphobia wrote:What do you normally use instead of cURL and wget?
by Aibohphobia » Mon Aug 12, 2019 4:54 pm
Thank you! That's really cool. Have you developed NS tools just for yourself or more "global" ones too?
by Trotterdam » Mon Aug 12, 2019 5:15 pm
To date I have not shared any of my tools, although I am of course sharing the results produced by my tools.Aibohphobia wrote:Thank you! That's really cool. Have you developed tools just for yourself or more "global" ones too?
To clarify: It's not clear that you have never worked with Qt. It is clear that you're not using it for your current application, since you explicitly said you're coding it in PHP.Aibohphobia wrote:Not sure where the "clearly" came from.
Congratulations!Aibohphobia wrote:I've managed to make it run after all. It just needed an X-Pin refresh, for some reason.
by Flanderlion » Mon Aug 12, 2019 6:08 pm
Trotterdam wrote:Congratulations!Aibohphobia wrote:I've managed to make it run after all. It just needed an X-Pin refresh, for some reason.
I'm not sure how that works, though. From what I understand of the API documentation, if the X-Pin doesn't work, the server should automatically ignore it and use your X-Password instead. You should supply an X-Password regardless, because X-Pins expire constantly (every time you log into your nation normally, for example).
by Trotterdam » Mon Aug 12, 2019 6:20 pm
Yes, I know that.Flanderlion wrote:You need the X-Pin though, as otherwise you get too many requests type errors after the first request or so.
by Aibohphobia » Tue Aug 13, 2019 6:02 am
Got it, thank you very much for clarifying. I was just curious. I like learning, and it would be nice to see how a knowledgeable person approaches a similar problem.Trotterdam wrote:I'd be entirely willing to share my API wrapper if anyone has any use for it, but like I said, it's designed for a fairly specific programming environment that isn't all that common in the NS scripting community.
The API isn't phrased perfectly, I concur. For example, it doesn't explicitly say that X-Pin and X-Autologin are returned only if you access a private shard (yes, even when X-Password is provided as one of the headers for the request). Certain shards (such as the ones I initially inquired about) lack proper documentation (at least in the form of something like on-hover tooltips).Trotterdam wrote:I'm not sure how that works, though. From what I understand of the API documentation, if the X-Pin doesn't work, the server should automatically ignore it and use your X-Password instead. You should supply an X-Password regardless, because X-Pins expire constantly (every time you log into your nation normally, for example).
It's very kind of you to remember. I sent him a telegram with a link to my source code as soon as I had got it done. To be honest, I don't really understand why he didn't address me in the first place, because we are from the same region, talk reasonably often, and he requested the source code for the previous version of my bot. I think I even shared my remastered version of Wolfram and Hart's script with him at some stage, but I might be wrong. He knows I work with PHP and JavaScript.Trotterdam wrote:If you got it to work, you should compare notes with SherpDaWerp, who is also using PHP/cURL and seems to still be having problems.
I disagree. The previous version of my bot did not work through the API, and I was simply scraping raw HTML through cURL (I come from an age where API's did not exist, I feel more comfortable with doing that, and I didn't realise responding to issues without using the API would get banned at any stage, because a moderator gave me "the green light" for a script that didn't affect other nations or the region's activity log). My script survived on the same '__cfduid=get-your-own; pin=tasty; autologin=cookie;' cookie for almost 3 years, excluding a short period where my server's IP address was banned by the site. Naturally, I logged into the nation manually every now and then. I highly doubt it's any different through the API, but I'll see soon enough. If it's different, I'm in for more code rewriting tomorrow.Trotterdam wrote:Yes, I know that.Flanderlion wrote:You need the X-Pin though, as otherwise you get too many requests type errors after the first request or so.
On your first request you supply only an X-Password, and memorize the X-Pin that you get in response. On subsequent requests you supply both, and continue rememorizing the X-Pins that you get in response in case it changed.
You most definitely do not hard-code any particular X-Pin into your script.
by Trotterdam » Tue Aug 13, 2019 6:26 am
It's a fairly recent rule, introduced mostly for the sake of the card minigame. If you've been doing it for 3 years, it was legal for most of that time. The rule change was not well-advertised if you're not following the Technical forum.Aibohphobia wrote:I didn't realise responding to issues without using the API would get banned at any stage
That would be it. As explained in the documentation, an autologin serves essentially the same purpose as a password, behaving closer to a password than a PIN. You still need to supply either a password or an autologin, the PIN by itself won't do.Aibohphobia wrote:My script survived on the same '__cfduid=get-your-own; pin=tasty; autologin=cookie;' cookie for almost 3 years,
by Aibohphobia » Tue Aug 13, 2019 7:21 am
As you can probably see from my stats, I rarely post, and I think all of my posts are in Technical and "Help Us Fix Old Issues". There is mixed information about this change, and I was lucky enough to get warned by a kind soul about it.Trotterdam wrote:It's a fairly recent rule, introduced mostly for the sake of the card minigame. If you've been doing it for 3 years, it was legal for most of that time. The rule change was not well-advertised if you're not following the Technical forum.
It's actually worse. I got this issue before (when I mentioned having to update the bot's X-Pin). If you log in your nation manually (even without checking "Remember me"), it somehow screws the API commands (they result in 409's afterwards)! I am referencing a private shard and trying to run commands on my end. The shard works fine with the old X-Pin, but API commands result in this:Trotterdam wrote:You still need to supply either a password or an autologin, the PIN by itself won't do.
I'm not sure what the benefit of using X-Autologin is. The documentation says it lets you avoid having to store your password anywhere, but wouldn't someone else who learned your autologin code be able to steal your nation just as well as someone who learned your password?
Previous Login Too RecentI am assuming, this is a block on commands only, because scraping raw HTML never resulted in that problem. So one needs to run a check on the response from the server for API commands functionality. And, unlike what the API documentation says (or some forum post - I don't remember), "waiting for about 6 seconds" doesn't resolve the issue. The server responds with 409 until the X-Pin is renewed.
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
by Trotterdam » Tue Aug 13, 2019 12:30 pm
The unnamed moderator who posted that is incorrect.Aibohphobia wrote:There is mixed information about this change,
Yes. That's what the documentation says.Aibohphobia wrote:The server responds with 409 until the X-Pin is renewed.
Again, look at the flowchart in the documentation. Autologin is only checked if your PIN is invalid, which will happen all the time, because PINs are being invalidated constantly (anytime you log in elsewhere, anytime you go two hours without doing anything).Aibohphobia wrote:As for the second part of your post, X-Autologin doesn't work without an X-Pin, as far as I know.
I don't get what you mean.Aibohphobia wrote:Update: The 409 problem is really annoying. It produces invalid HTML to begin with, but one can check for it through a dummy request (like 'nation=testlandia&c=issue' - without supplying 'issue' or 'option') and test it against a regular expression afterwards.
by Aibohphobia » Tue Aug 13, 2019 8:42 pm
It's important to me in determining whether I am sane and remember things well. After receiving that message from the moderator, I was afraid I had been breaking the rules all that time.Trotterdam wrote:I suppose that when the rule was made doesn't matter much. The important thing is that it's illegal now, and whether or not it was illegal a year ago isn't much help unless you have a time machine.
What the documentation and the 409 message tell me is that once an X-Pin is set, it doesn't need to get renewed (and it doesn't for private shards, the issue's only present with commands).Trotterdam wrote:That's what the documentation says.
Where are you even getting your X-Pin from, if your script is never managing to connect without it? Are you grabbing it straight from your browser cookies? That's pretty clearly not how it's supposed to work (unless your script is actually running in your browser, I guess - I hadn't actually considered that design). Scripts should be able to work on their own, entirely separate from your browser access to the game.
None of this is in the documentation. The flowchart is nice, of course, but it doesn't say how to check for X-Pin validity. The documentation should really be more clear on that.Trotterdam wrote:Again, look at the flowchart in the documentation. Autologin is only checked if your PIN is invalid, which will happen all the time, because PINs are being invalidated constantly (anytime you log in elsewhere, anytime you go two hours without doing anything).
How would you identify a valid X-Autologin? Compare it to an empty string?Trotterdam wrote:If you have a valid-looking X-Autologin, then make your request sending both that X-Autologin and, if you also have an X-Pin, that too. If that works, memorize the X-Pin the server returns, and repeat step 3 as often as necessary to finish your script
When you say "save to disk", what exactly do you mean? Saving it to a file? What's the advantage of that compared to having the value in plaintext inside the script itself?Trotterdam wrote:save the former to disk
That doesn't really work for me, as I am running it from my server's crontab. It doesn't receive any user input.Trotterdam wrote:prompt the user to enter a password
Sorry, it was very late. I meant that the 409 page is not in XML format. Checking for the status code didn't occur to me, because I was falling asleep.Trotterdam wrote:I don't get what you mean.
You should only check the XML if your request got a 200 response code. Otherwise, you should just check the HTTP response code and ignore the actual text returned. In PHP/cURL, you appear to do this using curl_getinfo($query, CURLINFO_RESPONSE_CODE), according to the manual.
by Trotterdam » Tue Aug 13, 2019 10:34 pm
You don't check the X-Pin for validity. You send it regardless of if it's valid or not (unless it's a completely empty string), and the server will automatically ignore it, and fall back to the X-Password and/or X-Autologin that you supplied at the same time, if it's invalid. Similarly, you always check the server's response for a new X-Pin, which, if supplied, automatically implies your previous one is invalid and should be replaced.Aibohphobia wrote:None of this is in the documentation. The flowchart is nice, of course, but it doesn't say how to check for X-Pin validity. The documentation should really be more clear on that.Trotterdam wrote:Again, look at the flowchart in the documentation. Autologin is only checked if your PIN is invalid, which will happen all the time, because PINs are being invalidated constantly (anytime you log in elsewhere, anytime you go two hours without doing anything).
Yeah, that. Remember that the very next step amounted to "if the server complained your autologin was invalid, get a new one", so it's not a huge deal if you try to use an autologin you're not sure about. This is just to save you from sending a request that's really obviously not going to work.Aibohphobia wrote:How would you identify a valid X-Autologin? Compare it to an empty string?
Well, for one, that you're sure you're using the autologin correctly. It also lets the script update itself if you change your nation's password, rather than needing to muck with your code again every time that happens.
Oh, hmm. I guess you are stuck with hardcoding (or at least supplying in a non-interactive configuration file, which amounts to the same thing) either your password or your autologin, in that case. I still suggest you try to get your autologin from the X-Autologin header returned by a (possibly manual, but ideally from the same computer that's running the script) API request, rather than directly from your browser's cookies, just in case. If they are exactly the same, then at least checking it rules out one possible source of error.
That's not quite right, though. Your login.php should only grab the X-Autologin. X-Pins expire too frequently to be useful "prepackaged", and should be constantly checked in your main script, not your login.php.Aibohphobia wrote:I have a separate login.php script that I grab the X-Pin and X-Autologin from by running it manually once. It seemed ridiculous to me (and it still does) to check if the X-Pin is "current" for every bloody API command. It's 1 additional API request that is completely unnecessary given the "rigorous" system we're dealing with. According to the documentation, the whole point of having an X-Pin is so that you don't have to authenticate every time you issue an API command. Otherwise the easiest way for me to send them is by simply using X-Password and ignoring the other custom headers.
curl_setopt($ch, CURLOPT_HEADER, true);
$response = curl_exec($ch);
$curl_info = curl_getinfo($ch); // Equivalently, $header_size = curl_getinfo($ch, CURLINFO_HEADER_SIZE); should also work.
curl_close($ch);
$header_size = $curl_info['header_size'];
$header = substr($response, 0, $header_size);
$body = substr($response, $header_size);
by Darcania » Sat Aug 17, 2019 3:28 pm
by Aibohphobia » Sun Aug 18, 2019 10:03 pm
That's too much trouble. It's easier to always use X-Password or always renew X-Pin without checking its validity. Additionally, as noted before, the current API commands do not work if a valid X-Autologin is provided. They require a valid X-Pin or X-Password.Trotterdam wrote:You don't check the X-Pin for validity. You send it regardless of if it's valid or not (unless it's a completely empty string), and the server will automatically ignore it, and fall back to the X-Password and/or X-Autologin that you supplied at the same time, if it's invalid. Similarly, you always check the server's response for a new X-Pin, which, if supplied, automatically implies your previous one is invalid and should be replaced.
Those are all very good points. I concur.Trotterdam wrote:Well, for one, that you're sure you're using the autologin correctly. It also lets the script update itself if you change your nation's password, rather than needing to muck with your code again every time that happens.
If you were writing the script for anyone else, it would also make it more user-friendly by not requiring any user input that requires technical expertise (since the only user input is the password like you'd type on a normal login, not autologin). Maybe not a concern for your use case, but something I try to think about.
It's really annoying, because it completely removes the layer of security X-Autologin and X-Pin are supposed to provide.Trotterdam wrote:I guess you are stuck with hardcoding (or at least supplying in a non-interactive configuration file, which amounts to the same thing)
The next iteration of the script will remove login.php completely, as I will have to revise the logic behind it after receiving your feedback.Trotterdam wrote:X-Pins expire too frequently to be useful "prepackaged", and should be constantly checked in your main script, not your login.php.
I know how to separate headers from body, but I appreciate you quoting the code. I will indeed have to do just that... Thank you very much for your continued help.Trotterdam wrote:I guess you will then need to do some string processing to locate a line in $header that starts with "X-Pin: ", and if found, update the X-Pin that you send on subsequent requests to match. Then process $body as you normally do. Checking the HTTP response code (curl_getinfo($ch, CURLINFO_RESPONSE_CODE) or $curl_info['http_code']) should be done after you process $header but before you process $body (continuing with the latter only if the response code is equal to 200).
Advertisement
Users browsing this forum: Bali Kingdom, Countriopia, Tamocordia, Trotterdam
Advertisement