emreozcan / nepojang Goto Github PK

The profilehistoryadd utility outputs Name not available. when trying to change a profile's name to a different capitalization.

There isn't actually a problem with the DB implementation. This is possible to do using custom Python code. The utility checks if the name is available to anybody using the static method Profile.is_name_available.

Currently, you can change a profile name to anything that isn't taken at that moment. Profile names should have 37 day grace period to reach parity.

This can already be achieved by filtering the given profile's ProfileNameEvents with an active_from greater than the given time and sorting them to find the newest one.

There should be a method (most likely inside of Profile) that does all of the above and returns the relevant ProfileNameEvent or the name. I think returning the ProfileNameEvent is more useful.

You don't need to answer security questions to change skin currently. The official API does not trust your IP enough to allow skin changes before you answer 3 security questions. (We'll require answers for all questions on the account since we support more than 3 questions.)

API should return custom error if request JSON structure is incorrect.

Assume a profile exists for an agent "Agent1" with the name "Profile". Another profile with name "Profile" should be able to be created for a different agent such as "Agent2". This is currently impossible because all agents share a single profile table with unique constraints on name, name_lower and name_upper.

If a profile's name doesn't get changed for 37 days, its name will become available regardless of whether it is currently being used or not. We have to check if a profile with the given name exists in Profile.is_name_available_for_creation.

API should return custom error if Content-Type is set incorrectly.

Scripts/utilities are needed for database manipulation. You have to do everything with Python code at the moment.

Here are a few utilities I can think of:

• account creation
• account listing
• account editing
• account deleting
• profile creation
• profile editing

Online server authentication needs to implemented for the project as a whole to be useful.

There isn't anything we need to implement before this. All the systems required are already in place.

Response accessToken from authserver.mojang.com doesn't include the spr tag!

Expected format:

{
    "sub": "cb5086961a6449b4b799904de50b8813",
    "yggt": "e0b49660785f4008841e6bfb7944b66e",
    "spr": "346d0e64c7a24547ad1440eaf8fd3b15",
    "ssr": "Yggdrasil-Auth",
    "exp": 1578009600,
    "iat": 1577836800
}

Actually received:

{
    "sub": "cb5086961a6449b4b799904de50b8813",
    "yggt": "e0b49660785f4008841e6bfb7944b66e",
    "ssr": "Yggdrasil-Auth",
    "exp": 1578009600,
    "iat": 1577836800
}

Profile name change isn't supported right now. You can change profile names with Python or SQL but it's probably not going to work like that in the future.

We'll probably have to implement a db entity NameChangeEvent. Whatever we do, the solution must support looking up the name change history, and must support finding out the name of the profile at any given time.

The answering of security questions must be implemented in api.

Before this can be done, changing and setting the security questions must be implemented, which isn't in the official API. We will make a proprietary system for this.

This system will handle account creation and management, profile creation, profile name changing, cape and skin management and security questions.

• Get list of security questions
• Answer security questions
• Trust IP address based on security questions
• Add security questions to existing accounts

Official authlib library checks JWT responses against Yggdrasil's public key. We will have to find a workaround for this.

We will probably have to create a replacement for authlib that doesn't check signatures or checks against multiple public keys, or replace the public key they're checking against.

If we create a replacement, Nepojang will be able to used in Java applications pretty easily. But it is a lot of work and nobody will probably want to use a system specialized for one game anyways.

If we replace the public key they're checking against, since we cannot distribute the authlib.jar, the install process will be a little bit more tedious.