3. Auth Tokens

Auth Tokens

  • Culture

    What about putting a limit on how much can be pushed through the console? For example, limiting the string length for console.log, or a max console.log total volume per tick. This would have the added benefit of working for all cases of console overuse, rather than just limiting stats. For example if you thought Quorum was pushing too much data through console, even though it is a bunch of short messages with no "stats", this would prompt some limiting.

    I agree here, it makes sense for there to be a console volume limit, per tick. That can also be easily worked around by the user by queuing and prioritizing messages to stay within the limits.

    The other thing to consider is that there are really three main stats programs (screeps-stats, screeps-grafana, and screepsplus) that are used by the community at large, and they are essentially managed by three people (myself, @ags131, @Dissi). I'm pretty sure the three us will commit to not pushing stats over console if we're specifically told not to, and will refuse to merge any PRs which enable it. I know there are other individuals who have their own setup that's separate from that, but it may be a matter of simply sending your "high console users" a message to let them know they're putting too much strain on the system.

    Agreed here too, if I'm asked not to do something (Such as using console for stats). I'll update the ScreepsPlus stats agent to remove that capability and encourage users to update and switch to another method.

    My primary motivations for using the console for stats output is live per-tick stats, polling the API endpoints every 3 seconds (Or whatever the tick rate is on that shard) is IMO way too many HTTP requests to be doing constantly, while the websocket stream is a steady trickle without the extra overhead of individual HTTP requests. I also dump a copy of every console message and error into rotated text files for easy searching, it makes debugging infrequent errors easier.

  • Dev Team

    @tedivm

    This is a bit more complicated, but I have an idea that might work for clients such as this.

    1. Client authenticates to /api/auth/client.
    2. /api/auth/client returns two values- an authentication token and a URL.
    3. The Client then exposes the URL to the User.
    4. The user clicks the URL, which brings them to a screeps page (presumably in a browser, not necessarily a webview) that includes the reCAPTCHA.
    5. Upon clicking the "enable" button the token given in step 2 is activated for six hours.

    What's difference here from usual /api/auth/signin flow (with reCAPTCHA enabled starting from February)? Looks like the same principle to me.

    1 Reply
  • Culture

    @artch the main difference is that in my example no one has to embed a recaptcha directly in their program (which, after looking at it, i'm not sure is even possible for many applications). I just think it'll be easier to impliment.

    1 Reply
  • Dev Team

    @tedivm You can open the URL directly instead of embedding it in an iframe or a web view, that's the decision of the client developer and has nothing to do with how the server works.

    1 Reply
  • Culture

    @artch said in Auth Tokens:

    @tedivm You can open the URL directly instead of embedding it in an iframe or a web view, that's the decision of the client developer and has nothing to do with how the server works.

    Then I'm not sure I understand how that would work. Where does the URL for the iframe come from and how does it lock itself in to a specific token?

    1 Reply
  • Dev Team

    @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.

  • Overlords

    I've had a confusing discussion on Slack around the rate limit on POST /api/user/code.

    I updated rollup-plugin-screeps to require a token when pushing to screeps.com which causes its deploys to be rate-limited to 10 per hour.

    I've been told that grunt-screeps doesn't get rate limited, but when looking at the code I thought it was because it is still using username/password authentication (https://github.com/screeps/grunt-screeps/blob/master/tasks/screeps.js#L61). Is it not going to need updating?

    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?

    2 Replies
  • Culture

    @arcath node-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.

  • Culture

    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?

  • Overlords

    @ags131 said in Auth Tokens:

    @arcath node-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.

  • Dev Team

    Update

    • There is now a way to turn off rate limiting for a specific token for 2 hours, see documentation.

    • Limit values are updated. Some limits are per-day now.

    • Two new endpoints added to token access scope:

      • GET /api/user/money-history
      • GET /api/market/my-orders

    • Added an option to add description to a token.

    • New endpoint /api/auth/query-token?token=XXX which shows the access scope and unlimited period timer for a token.

    • Endpoint /api/user/memory-segment now accepts segment query param as a list separated by a comma.

    👍
    1 Reply
  • Dev Team

    @arcath Basic auth will become rate limited using the same limits soon. You are better off using tokens, since you can now turn off rate limiting for tokens, unlike basic auth which is always limited.

    👍
  • Culture

    These updates are fantastic, thank you!

    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-

    1. 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.

    2. 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.

  • YP

    3rd party tools should never ask for the username/password. That was the reason why we asked for tokens in the first place.

    👍
    1 Reply
  • Culture

    @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.

    1 Reply

  • @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.

    1 Reply
  • Culture

    @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.

  • Dev Team

    The difference is that a token can be revoked at any moment.

    1 Reply
  • Culture

    @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.

    1 Reply
  • YP

    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.

    1 Reply