Kir-Antipov/mc-publish

Modrinth throws Authentication error

Closed this issue · 14 comments

Error: Failed to upload file: 401 (Unauthorized, {"error":"unauthorized","description":"Authentication Error: Error while communicating to GitHub OAuth2: error decoding response body: missing field `login` at line 1 column 80"})

See here: https://github.com/ReviversMC/unsaddle/actions/runs/4166216846/jobs/7210263184

The description of this error may suggest that there is an issue on our side (i.e., we did not specify some mysterious login field), but it actually stems from Labrinth (Modrinth's API) failing to validate the content of the GitHub OAuth2 response before its deserialization. In other words, GitHub rejected the token you provided and returned an error response that could not be parsed by Labrinth, causing a deserialization exception to be thrown. This indicates that your token has either been revoked or has expired. To resolve the issue, you need to provide mc-publish with a new token.

To avoid having your tokens expire randomly, you can generate your own token with custom options in the "Personal Access Tokens" tab of your GitHub personal settings. Note, that only the permission to "Read all user profile data" is required by Modrinth. DO NOT grant tokens without an expiration date permissions to access your repositories, packages, or any other important things associated with your account. However, it's not a bad idea for tokens to periodically expire because of security reasons. So, the best practice here would be to request a new token from Modrinth once a month and update all projects that depend on it.

Also, you could ask Modrinth devs to fix this quite confusing error description ;)

I'll pin this issue for now so that other users can quickly find a solution when they inevitably encounter the same problem.

Closing the issue, but if you have more questions (or in case the problem persists) feel free to let me know how can I help you!

I remember saying that uploads only need Modrinth's Token to upload, didn't understand why they would return a 401

image

Error: HttpError: 401 (Unauthorized, {"error":"unauthorized","description":"Authentication Error: Authentication method was not valid"})

Which scopes does the Modrinth token require?

The action run in question: https://github.com/Forsaken-Borders/Apollo/actions/runs/6600915516/job/17932871717

@OoLunar, #88

The README is already massive, so I would love to reduce its size, not expand it further. I am currently working on creating a standalone documentation for the project where I can provide detailed information on every aspect, including instructions on how to obtain the required tokens.

At the moment, here is the complete list of permissions that mc-publish may require:

  • Read projects - this permission is necessary to filter out unsupported loaders for the given project

  • Write projects - this permission will be required when I implement Allow specifying the environment of the mod (CurseForge only) #64

  • Read versions - this permission is essential for the unfeature functionality to work

  • Write versions - this permission is also needed for the unfeature functionality to function correctly

  • Create versions - well, this is the whole purpose of mc-publish

@Kir-Antipov thank you for the quick response. Unfortunately even after giving my Modrinth PAT the correct permissions, I'm still having the same error. I even tried modifying the PAT to have all permissions, however that didn't work either. Would you like me to create a new issue for this?

@OoLunar, actually, wait. Are you sure that you didn't forget to set the key's value?

This is your action's log, and it seems that GitHub cannot provide a token value to mc-publish because it's absent:

##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'MODRINTH_TOKEN'
##[debug]=> null

It... certainly shouldn't be...

image

I'll just replace it and run a brand new run.

Unfortunately I still seem to be having the same issue. I'm not sure what's the problem here.

Regardless, this doesn't seem like an issue with your action. Beyond a null check, I don't think there's anything you could do.

Thank you very much for your quick assistance! I appreciate you making this action and I look forward to being able to use it.

Beyond a null check

Actually, there is a null check:

if (!platformOptions?.token) {
continue;
}

If a falsy value is provided (e.g., false, null, undefined, "", etc.), the action won't even attempt to publish your assets. The problem here lies in the fact that GitHub Actions stringify their inputs. So, instead of false, for example, I receive "false"; or, as in this case, "null" (i.e., a string) instead of the true null value.

Thank you very much for your quick assistance! I appreciate you making this action and I look forward to being able to use it.

Thank you for the kind words! Sadly, I have no idea what could have gone wrong with the GitHub Runner in your case and why it refuses to provide the specified value. The only possibilities I can think of are:

  1. Maybe you have a really evil typo somewhere, e.g., MODRlNTH_TOKEN instead of MODRINTH_TOKEN, or something similar.
  2. Maybe it's somehow connected to the fact that this is an organization repository, not a personal one. Though, repository-level secrets typically don't require additional authorization.
  3. Maybe this is a problem with the debug mode? Have you tried running the workflow without it being enabled?

Maybe you have a really evil typo somewhere, e.g., MODRlNTH_TOKEN instead of MODRINTH_TOKEN, or something similar.

I thought this was the case too (and prayed it wasn't), so I just copied and pasted the secret name from the screenshot above into the action. No dice.

Maybe it's somehow connected to the fact that this is an organization repository, not a personal one. Though, repository-level secrets typically don't require additional authorization.

I thought that too. "Oh maybe secrets require additional authorization like Dependabot does." This did lead me to my solution!

Maybe this is a problem with the debug mode? Have you tried running the workflow without it being enabled?

With and without, yep yep. That didn't make a difference either, beyond a little bit of more information.

GitHub's Composite Actions

Apparently, when you call workflow B from workflow A, GitHub changes a few things. As per the GitHub docs, there are a few behavioral changes made for security reasons. One of those changes is that secrets must be explicitly passed to the invoked workflow.

I wish I knew this before thinking "Oh I'll just reuse my tag workflow so I don't have to have some code duplication. All I have to do was add the workflow_call and then it's done!" I oh so foolishly thought.

Fast forward and hour later and here I am asking for help on this issue. "My secrets are now undefined for whatever reason, am I using your action incorrectly?" No, not at all! I'm using MY action incorrectly because I didn't explicitly request which secrets to use!

  workflow_call:
    secrets:
      MODRINTH_TOKEN:
        description: 'The token to use for Modrinth authentication'
        required: true

This just about drove me insane and I apologize for dragging you through with me. Hopefully my troubles assist someone else, though I prove doubtful. Thank you once more for having great patience with me, it really does mean everything to me.

Oh, that's what happened to you! This is interesting. I completely missed the fact that you call the workflow in question from somewhere else, to be quite frankly honest with you.

I'm very glad that you've figured it out! Also, thank you for the detailed, textbook-worthy explanation of your situation. I will definitely feature it on the Wiki when I'm finally done with it (god, I'm working on too much stuff right now), because this is something users should be notified about, so they won't encounter the same seemingly strange errors as you did.

This just about drove me insane and I apologize for dragging you through with me. Hopefully my troubles assist someone else, though I prove doubtful. Thank you once more for having great patience with me, it really does mean everything to me.

No need to apologize! The action was created to simplify the publishing process, not to make it harder. So, in some way, this is my fault that I still don't have a comprehensive guide on how to set up a GitHub Workflow and avoid any GitHub quirks in the process :)

And, once again, I appreciate the kind words, even though I wasn’t of much help in this situation, and you ended up finding the root of your problems yourself :)

I had this error and resolved it by grant create versions and write versions permisssion on Modrinth.