astra137 / node-mojang Goto Github PK

Something I considered a while back, but never ended up doing, was a client API where tokens are stored and used in subsequent requests:

const client = mojang.client({ user, pass, ... })

// Create and store token
await client.login()

// Make request that require a token
let valid = await client.validate()
let info = await client.user()
// skin requests?
// ...

To be honest I made the current API a while back as a very barebones way to wrap the requests. Things can redone/added if you want a more high-level wrapping of their API.

CVE-2018-3728
recommended: hoek ~> 5.0.3

This is for my own reference.

• dep bump
• patch async tests for new AVA
• maybe: change http error format
• maybe: change http library
• maybe: change docs from html to markdown

I notice in my old code there is some optimizations that I didn't make, which I would do now-a-days:

1. Stop using array built-ins (Array#forEach, map, reduce, etc.)
2. Stop using for (foo in bar) loops on objects, opposed to Object.keys + regular for
3. Caching some of the request options that never change between each call
4. Probably others. Like caching requests, early exits, etc.

As always, your guys' choice. If you want clean maintainable code, or optimized code.

The last weeks developing with this wrapper made me feel like communication requires a lot of workarounds. For example, when I'm doing a request with invalid user credentials I'd expect the promise to be rejected instead of being resolved with an error. The same unexpected behaviour is seen when using functions which return an empty payload if they were successful (like I mentioned in #5).
As @jamen already said some code optimizations #9 like would be useful as well.
I feel like implementing this into a new complete 2.0 rewrite would be more effective than using the existing codebase. I have some ideas for the rewrite and I'd like to hear your opinion on this.

• Test Coverage as high as possible (goal is 100%). Coveralls + Travis?
• Enforcing a consistent code style. Standard?
• Interactive API Documentation for the Mojang API. Swagger UI?
• ES6 features (Babel) vs. standard node runtime features?

I'd love to hear your opinion and if anybody would be willing to help me.

So I don't want to maintain this project because I don't do Minecraft dev. Let me know if you want to maintain it.

Some things to think about:

• Package needs tests
• Does not support skins
• Better support for authentication
• Any breaking changes? No updates in over a year

cc @seanc @Blazedd @modev @rom1504 @zekesonxx

Although the current authentication method in place for this library returns a session, it is a game session. Tokens generated from this type of authentication cannot be used with the online API. Instead, use the following format:

https://authserver.mojang.com/authenticate
POST
Header: Content-Type: application/json
Body:
{
"captcha":"string: captcha key",
"captchaSupported":"InvisibleReCAPTCHA",
"password":"user password",
"requestUser":true,
"username":"user email"
}

Where 'captcha' is an invisible ReCAPTCHA key. Assets and POST request data can be found on the minecraft.net login page using the Chrome debugger.

https://api.mojang.com/user/profiles didn't seem to be documented, but exists and makes it possible to get a Minecraft profile name with only a session access token. If this isn't already possible somehow, is there any reason not to add this endpoint? If not, I'll branch and request a pull.

Hello guys,

I've been working on implementing new wrappers to easily handle skin changes for users of this package. I have successfully wrote the methods for Change Skin and Upload Skin although I get the same error response when I send requests to them.

{"error":"Forbidden","errorMessage":"Current IP not secured"}

I have tried using the curl example provided on http://wiki.vg/Mojang_API#Change_Skin although I get the same issue. The only thing I can think of is that mojang is blocking access to this request. They shouldn't be doing this, though, because on the wiki page there is nothing specifiying that this api is not public. I've found no online resources except for an issue on their JIRA which describes the exact problem I am encountering. They marked it resolved with "works as intended", which makes me wonder if this is actually not a public api request.

Also this http://wiki.vg/Talk:Mojang_API
Deobfuscated code from the above link: https://hastebin.com/pawoyagewu.js

This is my implementation:

'use strict';

const request = require('./_request');

/**
 * 
 */
function changeskin(uuid, accessToken, slim, url){
    return request({
        method: 'POST',
        hostname: 'api.mojang.com',
        path: '/user/profile/' + uuid + '/skin?model=' + (slim ? 'slim' : '') + '&url=' +encodeURIComponent(url),
        headers: {
            Authorization: ' Bearer ' + accessToken,
        }
    });
}

module.exports = changeskin;```

I was casually throwing around cost-of-modules when I saw that mojang was taking up 1.69M of space in another project of mine. It seemed disproportionately large, so I want to see about trimming that down.

Obvious first step (which I forgot to do, sorry) is to not publish non-essential source files, which could be files field in package.json or using .npmignore. I don't which is semantically better yet. I'll read up and make a pull request.

When I was writing my the comments for my PR #4 I realized a bug which can get quite annoying.
When calling mojang.validate(access_token, client_token) with a valid access token/client token combination the promise gets rejected, since the operation returns an empty payload and if the data response is empty the promise gets rejected.
However calling the function with a invalid access_token the promise gets resolved, since

if(data.length < 1){
  return reject(new Error("No data received."));
}

rejects the empty payload.
I think this isn't too hard to fix, but probably it'd help if somebody would implement tests for this project first.