Skip to content

Notify the user when the file path contains leading or trailing spaces and fix the error message for invalid file names. #31507

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Sep 24, 2024

Conversation

charles7668
Copy link
Contributor

close #31478

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Jun 27, 2024
@github-actions github-actions bot added the modifies/go Pull requests that update Go code label Jun 27, 2024
Copy link
Member

@silverwind silverwind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems ok. Personally I would have tried to do it in frontend, but this is also fine and probably simpler than frontend stuff.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jun 27, 2024
for i, v := range treePath {
treePath[i] = strings.TrimSpace(v)
}
form.TreePath = strings.Join(treePath, "/")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, the path could be something like / / / /, just press Space Slash Space Slash on the editor page 🤣

Then the tree path becomes "////", which doesn't seem good.

This comment was marked as resolved.

This comment was marked as resolved.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then the tree path becomes "////", which doesn't seem good.

I assume the backend would reject that? Seems like right behaviour to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are more edge cases: for example, what happens to foo/ .. /bar? Will it be rejected or become foo/../bar then become bar?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GitHub has another good behavior: if ../ is inputted, then it changes the path to parent, not sure whether it is implemented in Gitea's UI.

Copy link
Contributor Author

@charles7668 charles7668 Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested with GitHub, I think GitHub also uses my suggestion: do not do too much for end users, only warn them.

On GitHub, it shows a warning but does not take any action for users. This is my test: 't2 / t3 / t4 /test'
圖片
圖片

This problem is the same as #31478.

I'm not sure if we need to follow this behavior or not.

Copy link
Member

@silverwind silverwind Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that GitHub has this warning, then I agree, we should implement it too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both approaches sound good to me.
Both get an LGTM from me.

Copy link
Contributor Author

@charles7668 charles7668 Jun 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

firefox_XPWa8Ls4eU

I added some warnings for users similar to GitHub.
However, I have kept backend processing for spaces.
On GitHub, it only removes spaces from filenames, not from parent directories. Since Gitea can run on different operating systems, leading or trailing spaces may cause some problems. Therefore, I have retained space processing.

@silverwind silverwind self-requested a review June 27, 2024 13:49
@GiteaBot GiteaBot added lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Jun 27, 2024
for i, v := range treePath {
treePath[i] = strings.TrimSpace(v)
}
form.TreePath = strings.Join(treePath, "/")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both approaches sound good to me.
Both get an LGTM from me.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels Jun 28, 2024
@delvh
Copy link
Member

delvh commented Jul 18, 2024

@silverwind could you review again?

@wxiaoguang
Copy link
Contributor

wxiaoguang commented Jul 18, 2024

  1. IMO trimming spaces in backend is not right (well, just my personal option, not a blocker if most people like this behavior)
  2. Coding style: showElem vs .style.display = ...
  3. There are still bugs, for example:

@charles7668
Copy link
Contributor Author

  1. IMO trimming spaces in backend is not right (well, just my personal option, not a blocker if most people like this behavior)

    1. Coding style: showElem vs .style.display = ...

    2. There are still bugs, for example:

      • input something like foo/../bar causes incorrect result.

How can this bug be reproduced? I tried it but couldn't reproduce it.
firefox_V5c0V4tfCL

   * `document.querySelector('.ui.warning.message.flash-message.flash-warning')` may query other "flash message" incorrectly but not the "space-related" one.
   * the concern in https://github.com/go-gitea/gitea/pull/31507/files#r1657163784 is still not resolved, I do not think making `/ / / /` to `////` is right for backend path handling.

I will fix the other bug.

@wxiaoguang
Copy link
Contributor

How can this bug be reproduced? I tried it but couldn't reproduce it.

Paste foo/../bar

# Conflicts:
#	web_src/js/features/repo-editor.ts
@charles7668 charles7668 marked this pull request as ready for review September 10, 2024 05:45
@charles7668
Copy link
Contributor Author

As an alternative to trimming spaces, I fixed the error message when the file can't be created.
圖片

Could you also change the title and resolve the conflicts?

Updated and CI error seems not related

@lunny
Copy link
Member

lunny commented Sep 18, 2024

It looks like I can still create a file name with trailing whitespace.
图片

@charles7668
Copy link
Contributor Author

charles7668 commented Sep 18, 2024

It looks like I can still create a file name with trailing whitespace. 图片

Based on this comment, I have changed the approach to not prevent users from creating spaces in the file name. Instead, a warning message will be shown if there are trailing or leading spaces, and an error message will be displayed if the file cannot be created on the server OS.

I think whether or not to process spaces in the backend can be proposed for discussion.

Leading or trailing spaces are allowed on a Linux server, but if using a Windows server, it will show an error message.

On the Linux server, this file can be created successfully.
On the Windows server, it returns the following page and fails to create the file:
In my opinion, for consistency, we need to maintain the same behavior across different OS servers.

That's impossible, naturally Windows and Linux are different, eg: the?file.txt, the*file.txt, the<file.txt, con, com1 .........

@lunny
Copy link
Member

lunny commented Sep 18, 2024

It looks like I can still create a file name with trailing whitespace. 图片

Based on this comment, I have changed the approach to not prevent users from creating spaces in the file name. Instead, a warning message will be shown if there are trailing or leading spaces, and an error message will be displayed if the file cannot be created on the server OS.

I think whether or not to process spaces in the backend can be proposed for discussion.

Leading or trailing spaces are allowed on a Linux server, but if using a Windows server, it will show an error message.

On the Linux server, this file can be created successfully.
On the Windows server, it returns the following page and fails to create the file:
In my opinion, for consistency, we need to maintain the same behavior across different OS servers.

That's impossible, naturally Windows and Linux are different, eg: the?file.txt, the*file.txt, the<file.txt, con, com1 .........

Yes. But no warning or error was displayed.

@charles7668
Copy link
Contributor Author

It looks like I can still create a file name with trailing whitespace. 图片

Based on this comment, I have changed the approach to not prevent users from creating spaces in the file name. Instead, a warning message will be shown if there are trailing or leading spaces, and an error message will be displayed if the file cannot be created on the server OS.
I think whether or not to process spaces in the backend can be proposed for discussion.
Leading or trailing spaces are allowed on a Linux server, but if using a Windows server, it will show an error message.

On the Linux server, this file can be created successfully.
On the Windows server, it returns the following page and fails to create the file:
In my opinion, for consistency, we need to maintain the same behavior across different OS servers.

That's impossible, naturally Windows and Linux are different, eg: the?file.txt, the*file.txt, the<file.txt, con, com1 .........

Yes. But no warning or error was displayed.

I referred to GitHub's behavior, which only checks when typing '/'. I have now fixed it to check after every typing.

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels Sep 21, 2024
@lunny lunny added the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label Sep 24, 2024
@lunny lunny added the backport/v1.22 This PR should be backported to Gitea 1.22 label Sep 24, 2024
@lunny lunny enabled auto-merge (squash) September 24, 2024 18:09
@lunny lunny merged commit 3269b04 into go-gitea:main Sep 24, 2024
26 checks passed
@GiteaBot GiteaBot added this to the 1.24.0 milestone Sep 24, 2024
@GiteaBot GiteaBot removed the reviewed/wait-merge This pull request is part of the merge queue. It will be merged soon. label Sep 24, 2024
zjjhot added a commit to zjjhot/gitea that referenced this pull request Sep 25, 2024
* giteaofficial/main:
  Notify the user when the file path contains leading or trailing spaces and fix the error message for invalid file names. (go-gitea#31507)
  Fix wrong status of `Set up Job` when first step is skipped (go-gitea#32120)
  Fix bug when deleting a migrated branch (go-gitea#32075)
  Include collaboration repositories on dashboard source/forks/mirrors list (go-gitea#31946)
  Display head branch more comfortable on pull request view (go-gitea#32000)
  Truncate commit message during Discord webhook push events (go-gitea#31970)
  Fix template bug of pull request view (go-gitea#32072)
@lunny lunny modified the milestones: 1.24.0, 1.23.0 Sep 25, 2024
@GiteaBot
Copy link
Collaborator

I was unable to create a backport for 1.22. @charles7668, please send one manually. 🍵

go run ./contrib/backport 31507
...  // fix git conflicts if any
go run ./contrib/backport --continue

@GiteaBot GiteaBot added the backport/manual No power to the bots! Create your backport yourself! label Sep 26, 2024
@lunny lunny removed the backport/v1.22 This PR should be backported to Gitea 1.22 label Sep 26, 2024
@lunny
Copy link
Member

lunny commented Sep 26, 2024

I think this can be kept v1.23 only.

@go-gitea go-gitea locked as resolved and limited conversation to collaborators Dec 24, 2024
@charles7668 charles7668 deleted the fix/new-file-space branch March 21, 2025 10:47
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport/manual No power to the bots! Create your backport yourself! lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. modifies/frontend modifies/go Pull requests that update Go code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider sanitizing filenames for whitespaces when creating a file from web interface
7 participants