#10377 "Bad Request" from my fedorapeople url
Closed: Fixed with Explanation 2 years ago by kevin. Opened 2 years ago by vanessa_kris.

Describe what you would like us to do:


Hello, please I newly joined fedorapeople.org following the docs
https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org
but when I visit my fedorapeople url (https://vanessa_kris.fedorapeople.org) I get "Bad Request"
Attached is a screenshot of the response

When do you need this to be done by? (YYYY/MM/DD)


Screenshot_from_2021-11-26_14-46-29.png


@vanessa_kris and I checked their folder permissions for both $HOME and $HOME/public_html, and they seem fine, so I'm not sure what else to look at for the moment.

This is due to the _ in the name. we never allowed underscores in the old account system and the web rules need adjusting.

Metadata Update from @mohanboddu:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: easyfix, low-gain, low-trouble, ops

2 years ago

Are we looking to:

  1. Have the user remove the underscore from their username
  2. Change the code to support underscore?

Which application is doing the data validation for the username?

AustinPowered

There's no way to do 1 aside from disabling the existing user and adding a new one

Allowing or disallowing _ is a thing in noggin. There's a bigger discussion about that. This ticket is just to make fedorapeople web space work with it for now until we decide at the higher level.

kevin: what do you mean by disabling and re-adding? Do you mean at FAS level? or simply fedorapeople? And if it's just fedorapeople, is it in ansible or directly modifying the users on the machine?

Thanks,
Leo

P.S. I am working together with austinpowered to solve this issue :)

So this issue (fedorapeople public_html space not working for a user with _ in their name) can be fixed by adjusting:

roles/people/templates/people.conf

RewriteRule ^([a-z0-9-]+).fedorapeople.org/(.*) /home/fedora/$1/public_html/$2 [L]

probably

If we wish to disallow _ in usernames, we would need to get noggin to disallow this, then disable every existing user with _ in their username and ask them to create new accounts.
That is beyond the scope of this ticket. I just want the cosmetic public_html thing fixed here.

Does that make sense?

The current rule allows usernames with lower-case letters only, numbers, and the '-' character. The rule also allows the '-' to be the first character.

RewriteRule ^([a-z0-9-]+).fedorapeople.org/(.*) /home/fedora/$1/public_html/$2 [L]

To allow '_' in usernames as well as the '-' the regex could simply be:

RewriteRule ^([\w-]+).fedorapeople.org/(.*) /home/fedora/$1/public_html/$2 [L]

I'm not sure if the '-' or '_' character should be allowed as the first character. The regex for that would be:

RewriteRule ^([a-z0-9]+[\w-]+)\.fedorapeople\.org/(.*) /home/fedora/$1/public_html/$2 [L]

If we all agree the '-' or '_' character should not be allowed as the first character, I will submit a PR with that rule.

All of these rules were tested using Regex101 Online Tester.

Thoughts?
AustinPowered

I would say lets not allow _ or - as first char. :) Otherwise it sounds good.

Just added PR-902 Issue#10377 - Allow underscore in fedorapeople username

So, with that pr, now:
https://fedorapeople.org/~vanessa_kris/
works

However https://vanessa_kris.fedorapeople.org/ dies not, and likely never will. _ isn't valid in dns hostnames. ;(

So, @vanessa_kris you may want to make a new account without the _ in it and close your current account.
We are going to adjust the account system to disallow _ in usernames, sorry for the hassle here. ;(

Let us know if you need any help with it.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

2 years ago

Thanks for all your help @kevin @austinpowered @leo . We'll get @vanessa_kris a new username without the underscore and re-do their group accesses etc.

Sorry for the hassle. ;(

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog
Attachments 1