41
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 21 Sep 2023
41 points (100.0% liked)
Programming
17117 readers
327 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Well that one:
No, it does not match.
AFAICT, this solution is working properly, but if you can find a URL that breaks it, please let me know.
Lmao ah yes, one of those
If you're not convinced with this you never will
You can just wrap your var with "new URL()" and have something faster, correct and easier to read, but I'm guessing you'll change your ways silently in a few years when you've forgotten about this interaction and managed to convince yourself it was your own idea!
Until then i guess you can add /c/whatev at the end of my two examples and find something else to criticize and decide not to support
I'm not trying to be combative, I'm trying to understand. I'd like to see the failure in action so I can appreciate and pursue the proposed solution.
But when I added the community bit to the first URL, the browser resolved it and stripped the credentials, so the resulting URL matched. But the example credentials weren't real so it's not a great test; if there's an real example I can test, please share it. Though I don't see why I'd auth to an instance just to view it from a different instance.
When I added the community bit to the second URL, it was not a match, as it shouldn't be. The pattern must match the entire URL.
You can find it in action on regex101 with the regex indeed matching the query string in the maliciouswebsite and not matching even just something with the port and no user/password
It is valid (just weird & not recommended) to give a user:pw combo to a website that doesn't ask for one in the headers. Browsers stripping it off is a different thing
The sheer number of things you have to take into account to properly parse a URL should convince you to not use regexes for it
The fact that it's less code, more correct, faster and more readable to use new URL() should also be enough to convince you to not use regexes
I meant to communicate that the Redirector addon uses the given pattern to see if the entire URL string matches, not part of it. So the malicious URL does not match.
I'm wondering if there's a real URL for which the Redirector approach will not work.