@tedivm The URL is always the same. It's in the account settings, but we can make its variant without UI with a special flag like https://screeps.com/a/#!/account/auth-tokens/reset?noui=1. It doesn't lock a specific token, since rate limiting is user-based, not token-based, so it simply resets the user counter (both for persistent auth tokens and for regular one-time tokens). A third-party client might use any token mechanism, and give this URL to the user every time the servers responds that it's required to proceed.

Unlike node-screeps-api which uses /api/auth/signin to get a token and then uses that token to push code it appears that grunt-screeps uses an auth header to send email:password. Is the header going to stay and not be rate limited?

Can you raise the ratelimit on GET /api/user/memory? Right now it is set at 60 per hour (once per minute). If possible (and I understand if this isn't) could that be made a "per shard" thing? If not can it be raised slightly- say 120 per hour?

@arcathnode-screeps-api also optionally uses a token directly skipping the /api/auth/signin step.
gulp-screeps has already been updated to use a token if supplied.

I'm using tokens if one is supplied and it requires you use a token for screeps.com

It was mentioned by @dissi-mark on slack that grunt-screeps didn't have a rate limit. From looking at grunt-screeps source it appears that POST /api/user/code takes an auth header that isn't rate limited? I'd like to know if this is the case so I can change rollup-plugin-screeps back to requiring a username/password to use that header.

I have one more idea, although it's just a convenience factor and is definitely not required. From a usability perspective it's easier for people to remember a username/password than it is to remember a token. It would be nice if third party tools could directly request a token from an endpoint that took the username and password.

POST /api/auth/gettoken - takes username and password, returns token.

The token would still be rate limited, and no other endpoints besides this one would work with the username/password combination without recaptcha.

Two scenarios I see for this-

People who use the third party client, such as @bonzaiferroni's 3d one, can simply type in their username/password like they already do. This way the client doesn't have to persist tokens for each user and server combination. This makes it easier on players who use multiple servers- or players who share a computer.

For tools like the standalone console, the autospawner, or the backup tool they can create the token directly from the tool itself, and then those tools can persist the token.

None of this is required by any means, but it would make it really convenient for people to install their new tools.

@w4rl0ck I disagree. There is essentially no difference from a "full access token" and supplying credentials, and for applications that are open source and self hosted it shouldn't make much of a difference. The reason a lot of the third party tool developers wanted tokens was for the things that weren't self hosted- for example, if @ags131 wants to create a central service where people can put a token in and get stats dumped into their screepsplus account.

@tedivm There is one problem with username/password login, even for open source and self-hosted software. Most of the time, no one goes through the effort of reviewing the code. Then you have to make sure the binary you download actually matches the code you reviewed - there's no guarantee that they match, and this step is even less common.

@jbyoshi most (not all, but most) of the third party tools aren't compiled so you don't have to worry about binary matching. This same problem exists for a variety of tools- mail clients being a popular one- and with the "full access" token granting "full access" there isn't much difference between a token and a set of credentials when it comes to access.

@artch a password can also be changed at any moment, and since the method I proposed still relies on a token for all major operations those tokens can also be revoked right after the password is.

I don't mean to get into an argument, and if this idea isn't a priority then that doesn't bother me all that much. From a security standpoint though this isn't as big of a deal as people are making it out to be.

Well I did not try but I think full access tokens should not let you change your email, password, cancel the account or link it to a steam account, open support tickets and other account stuff like that.

Also I think it's important to teach people to not enter credentials of whatever account to 3rd party sites.

@w4rl0ck for the record, Github themselves use the exact method I'm proposing for their API. Here's the relevant code on Gitconsensus. As much as I love Screeps I tend to consider Github to have much higher security requirements and they have no problem with this method.

Encouraging people not to enter their credentials into third party sites is super important, which is why I included it in the third party tools page right at the top. Another thing we should do is encourage them not to use the same password in multiple places, as that can result in it getting out and causing more issues. I totally agree with this.

However, if we're already encouraging people to open up a webview in their application for authentication (something that has come up in this thread repeatedly, and which would easily allow someone to screenshot or keylog credentials) there isn't much of a difference between that and an official way to get a token. This just adds a layer of convenience, especially for people who want to put one of these tokens on a mobile client.

However, if we're already encouraging people to open up a webview in their application for authentication (something that has come up in this thread repeatedly, and which would easily allow someone to screenshot or keylog credentials) there isn't much of a difference between that and an official way to get a token.

Just for the record - the https://screeps.com/a/#!/account/auth-tokens/noratelimit?token=XXX embeddable UI doesn't require authentication, it can be used by an anonymous visitor, there is no login popup. Its purpose is to solve CAPTCHA rather than to authenticate the user.

@tedivm for the record, I would never courage someone to enter his github credentials at any other site, nor do I think github states anywhere that you should do so. If I would enter my github credentials at other sites I would have serious problems at work.

@artch : I see a possible problem with the turning off rate limiting for 2 hours for specific tokens. Maybe those tokens should be changed that they can only used when enabled with the link.

The problem I see is that a 3rd party client could use up all daily usages of a endpoint, for example the memory access, while the limits are not disabled, so other scripts would no longer work at all for the day. Or does pressing the button also resets the api limits?

@W4rl0ck exactly. Github tells people not to enter their credentials into third party sites- just like we already do with screeps credentials on the third party page I wrote- but they allow the option for applications people are hosting on their own. If you download Github's own desktop client it doesn't ask you for an authentication token, it asks you for a username and password. If that's good enough for github I think it's good enough for screeps.