fix: Fix name validation consistency

[Its-treason]

Edit: Updated the PR, please read next comment

With this PR I want to fix validation problems when creating folder, requests or environments. All names now use a validation regex:

/^(?!CON|PRN|AUX|NUL|COM\d|LPT\d|^ |^\-)[\w\-\. \(\)\[\]]+[^\. ]$/

This regex ensures various rules when naming files on the file system, so users don't run into weird problems:

• Only allowing certain characters: a-z, A-Z, 0-9, _, -, ., (, ), [, ] and (Space) to ensure file name compatibility between operating and file systems
  • Everything from Portable Filename Character Set and (, ), [, ],
• Disallowing special cases, e.g., Windows file names must not end with a .
• Disallowing Windows Device names e.g., CON, NUL

You can test this regex on regexr: https://regexr.com/7l552

For reference for all limitations, I used:

• https://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names
• https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

I also removed the is-valid-path/isValidPathname check from the collection creation as this check was very strict and would not pass with names containing common special characters and a failed checked would only fail with an “An error occurred” toast. This should resolve #174

---

For the future we should make it, so all characters are allowed in the Request/Folder name, but the special characters are only saved in the .bru file meta and the file name is automatically stripped from special characters. This should then resolve: #189 & #388. But will take some time to fix as it is more complicated.

[lared]

Somewhat related to #365

[Its-treason]

I updated my PR to allow all special chars in request names, this should resolve #388, #189 & #174. I also updated the name length validation to 250 characters, 256 characters is the windows length limit, so 250 leaves some space for the file extension, this should resolve: #163, #378 & #501.

Example:

2023-10-06_21-49-51.mp4

Example with old project, created with the current bruno version:

2023-10-06_21-57-30.mp4

There might still some things to fix, I look into that tomorrow

[Its-treason]

Hey @helloanoop, this PR should be ready to be reviewed and merged now. After this, I can start working on updating the Postman/Insomnia importer to close #365

[Its-treason]

I update the sanitization Regex to match the directory regex. I noticed that it would be very hard for a language like Japanese to use Bruno with the other regex, because こんにちは & ありがとう would both be converted to _____.bru so only one would be allowed.

[nomorsug]

I think { and } should also be added to the regex as they are frequently used in postman collection and are allowed on unix/windows

/^(?!CON|PRN|AUX|NUL|COM\d|LPT\d|^ |^\-)[\w\-\. {}\(\)\[\]\!]+[^\. ]$/

[Its-treason]

I think { and } should also be added to the regex as they are frequently used in postman collection and are allowed on unix/windows

/^(?!CON|PRN|AUX|NUL|COM\d|LPT\d|^ |^\-)[\w\-\. {}\(\)\[\]\!]+[^\. ]$/

Hey @nomorsug, sorry for the confusion, but the Regex in my initial comment is not up-to-date anymore.

With the newest changes, you can use any character in the request name. To make sure filenames are valid, characters like ? or / will be replaced with _, but this only affects the filenames.

[nomorsug]

@Its-treason was talking about the folder names, this regex to be specific packages/bruno-app/src/utils/common/regex.js to allow for curly braces {}

[Its-treason]

@nomorsug Sorry, I forget about the directory regex. I updated it to match the request sanitization regex:

/^(?!CON|PRN|AUX|NUL|COM\d|LPT\d|^ |^\-)[^<>:"/\\|?*\x00-\x1F]+[^\. ]$/

This now disallows only the problematic special characters like ?, < & some other windows related stuff, while allowing {, } and much more like Japanese characters.

Thank you for pointing that out!

[cardonator]

what was the intention of this change? The previous wording was grammatically correct.

[cardonator]

@helloanoop can we get this PR reviewed/merged? It will dramatically improve file handling for environments.

[nomorsug]

@helloanoop any chance of this getting merged soon? Postman imports are still impacted by the incorrect validation and v1.0 has been released

[fzberlin23]

@helloanoop any chance of this getting merged soon? Postman imports are still impacted by the incorrect validation and v1.0 has been released

That would be very nice. I'm also struggeling with the fact that i cannot use "/" in my request names.

[fractalf]

Also looking forward to this being merged! :)
..this as been a show stopper for me since the Insomnia drama

[wouter-leistra]

Really needing this to get into Bruno to make it more usable (also using / in request names)

[Its-treason]

Really needing this to get into Bruno to make it more usable (also using / in request names)

Not sure when, or if this will ever be merged into Bruno. For now you can use my fork: https://github.com/Its-treason/bruno/releases/tag/nightly it's compatible with mainline Bruno and currently used by our Team, because it includes some performance improvements.

[trbtm]

Please fix this. This stopping me from switching to bruno.

[bremyozo]

Showstopper for my team too. @helloanoop

[daniel-tirzuman]

I also wanted to switch to bruno, so I started with a sample request (/products), renamed the request (/products/id), and I get error. (macOS, latest version).

This is a critical bug in my opinion and it's a blocker for me to switch to this app.

[fractalf]

For those tired of waiting for this and sick of Insomnia...

I found another lightweight (based on electron) client here:
https://github.com/flawiddsouza/Restfox

[Its-treason]

For those tired of waiting for this and sick of Insomnia...

I found another lightweight (based on electron) client here: https://github.com/flawiddsouza/Restfox

Or checkout my fork: https://github.com/Its-treason/bruno/releases/tag/nightly it includes this and many more fixes while being fully compatible with Bruno.

[helloanoop]

Hey everyone!

Apologies for such a late update on this. In hindsight, we should have prioritised and delivered a solution for this earlier.
We have been working on this issue over the last week.

The core solution in this PR is around normalizing the filename and replacing them with _.

const sanitizeFilename = (name) => {
  return name.replace(/[<>:"/\\|?*\x00-\x1F]/g, '_');
};

We are working on an improvisation on top of this PR that allows you to have more control over the filename under which the request data is stored. Here is the PR - #3094 tracking this work.

Our goal is to have this refined and delivered within the next two weeks. Thanks for your patience.

request-folder-names.mp4

[trbtm]

@helloanoop @lohxt1 any updates or timeline for this?

[melroy89]

I was reporting this bug (like accepting a / in the name) in Discord recently as well.. This PR might just solve everything and is isn't hard to implement this.