Usernames with Underscores cant use the API?

[BobHelper]

Preconditions and environment

• Magento version - 2.4.7-p4
• It seems a user with an underscore in their username cant use the API to get token

Steps to reproduce

Create an API integration to retrieve something simple using a cURL
Create a user with an underscore in the username i.e. john_smith
Create a role to use the API

Try: curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser_2025", "password":"e.g.password1"}"
Returns: {"message":"The account sign-in was incorrect or your account is disabled temporarily. Please wait and try again later."}

Then change the username in Magento back-end and remove the underscore. Re-run with the new username:

But this: curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser2025", "password":"e.g.password1"}"
"returns the access token that we need"

Expected result

curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser_2025", "password":"e.g.password1"}"
"returns the access token that we need"

Thats what I expected.

Actual result

This is what you get if the username has an underscore:

Try: curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser_2025", "password":"e.g.password1"}"
Returns: {"message":"The account sign-in was incorrect or your account is disabled temporarily. Please wait and try again later."}

Additional information

No response

Release note

Whilst not severe, this does require a workaround to remove the underscore. I have had a quick dig around but can't find any reference to not using underscores in User Names and if it is an issue then underscores should not be permitted when creating a username?

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @BobHelper. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[BobHelper]

Also related to this, the API user account is locked out if the incorrect password is used 6 times to log into the Admin web backend. Yes, you can only view the resources that were set up for the Role associated with the API user. HOWEVER - If you use an incorrect password many, many times when requesting a token via the API, the account is not locked out. Is this by design?
I should add that this is a fresh install and a test site. No modifications, extensions etc. Just the sample data loaded and a few test orders input.

[m2-assistant]

Hi @engcom-Bravo. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• 5. Add label Issue: Confirmed once verification is complete.
• 6. Make sure that automatic system confirms that report has been added to the backlog.

[BobHelper]

I should add that this is the first time I've deployed Magento 2 so still learning - be kind :-)

Update cloned the repository and installed 2.4-develop:
rob@magento:/var/www/magento2$ bin/magento --version
Magento CLI dev-2.4-develop
rob@magento:/var/www/magento2$

I can confirm that a user with an underscore in their name CAN retrieve a token:

curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser_2025", "password":"eg.Password1"}"
"eyJraxxxxiSFMyNTYifQ.xxxxxxxxwLCJleHAxxxxODg3MzB9.txxxxxxxxx"

Not sure why, but where does that leave me with version 2.4.7-p4 for the underscore in username issue?

However for the API calls with a bad password:

curl -X POST "https://examplemagentosite.com/rest/V1/integration/admin/token" -H "Content-Type: application/json" -d "{"username":"APIUser_2025", "password":"Bad.eg.Password1"}"
{"message":"The account sign-in was incorrect or your account is disabled temporarily. Please wait and try again later."}

I've run that 10 times and the APIUser_2025 account does not get locked out.

2 Questions:

Is the underscore issue just present in 2.4.7-p4?
When calling the API with a bad password, should the account get locked out?

[engcom-Bravo]

Hi @BobHelper,

Thanks for your reporting and collaboration.

We have tried to reproduce the issue in latest 2.4-develop instance and we are not able to reproduce the issue.Kindly refer the screenshots.

We are able to retrieve the access token for the admin user with username underscore.

Kindly recheck the issue in latest 2.4-develop instance and elaborate the steps to reproduce if the issue is still reproducible.

Thanks.

[BobHelper]

Yes - We've both been doing the same thing. See my update prior to yours and the 2 questions.

2 Questions:

Is the underscore issue just present in 2.4.7-p4?
When calling the API with a bad password, should the account get locked out?

So....

The underscore is less of an issue, but what about the API calls with a bad password?

Thanks

[BobHelper]

Further update - fresh install of 2.4.7-p4 on a new server - created the same user 'APIUser_2025' with the same role and API configuration. It just worked first time. I'm stumped as to why it did not work originally.

However, same issue with using the API with bad password = account does not get locked out or rate limited with multiple scripted attempts with bad passswords.

[BobHelper]

@engcom-Bravo - I don't seem to be able to add / update the label 'Needs Update' - I've updated the info. Apologies this is a new area for me.

[engcom-Bravo]

Hi @BobHelper,

Thanks for your Update.

Created username with underscore and we are able to retrieve the access token successfully.Regarding when we are hitting the bad password the account does not get locked out.To proceed further we are considering this as enhancement and marking this as Feature Request.

Thanks.