Happy New Year everyone! I hope 2024 brings us more love, peace and knowledge.
203 karma · joined May 2, 2021
Besides that, Merry Christmas and Happy Holidays to everyone!
The source code is hosted on GitHub: https://github.com/often/icy
On a side note, those who write router software like this need to step up their security and stop being lazy. Seriously.
You can view the source code at: https://github.com/often/wt
A live preview is available on: https://wt.sany.one
The entire project is licensed with GNU GPL-3.0.
When you think a bit better about it, it's about the same as regular web browsing. Just automated or scripted.
I don't think there is much that can be done to fully prevent it either, so.
I also believe that the same anti-debugging technique is used by obfuscator.io, and is just a feature you can enable for when obfuscating your code on there. It's called "Debug Protection". It does about the same thing you shown in your blog post, making good use of the debugger statement.
It uses the GitHub Licenses API to fetch the licenses.
Website: https://licenses.sany.one
GitHub repository: https://github.com/often/licenses
website: https://palette.sany.one
source code: https://github.com/often/palette
hope you like it!
Nowadays, <meta name="viewport" content="width=device-width"> works just fine.
But in my opinion I think that you should make the website fully work without the use of client-side JavaScript.
Not that I dislike JavaScript, in fact, I love it. And it's great! But there are several reasons I think that this would make sense doing.
Here is a detailed explanation for "why":
The website already works without the use of client-side JavaScript, only not the index.
If you for example go to: https://per.quest/https://example.com it will work just fine and redirect you to the generated MP3 file.
But if you put https://example.com inside of that input on the website index and have JavaScript disabled it simply won't work. There also is no notice that it does not work without JavaScript enabled.
The solution to this is simple and I think that it would not be hard to change the way you are getting the user given URL from your back-end. What I think would make more sense doing is to just make it work using a URL query parameter.
For example: https://per.quest?url=https://example.com
... which would then allow you to make use of HTML forms, and simply add the "name" attribute to the input with the value set to "url".
So, this would then work in both cases: when the user hit enter and/or pressed a button inside of the form.
Hope that you will agree with me on this!
I have just checked out your forum and it does not seem to have any sort of form protection (stuff like hidden form inputs or captchas to solve). This tells me that it would be pretty easy to create some automated script to overload your backend. Well, unless your backend has specific checks or ways to prevent this.
basically, made for fun. I hope someone benefits from it?
That is fair, to be quite honest. Even though I don't see JavaScript as some kind of threat, your point still stands. Note that leader does not disrespect user privacy in any way, and that it is open source, which means you could modify it to your liking. By this I also want to say that it does not include unnecessary code, and that everything dependant on JavaScript is there with a reason (to make the website functional).
What leader aims to do is to speed up and simplify the process of creating your very own simple blog, and I think it does a great job at that.
Since it does not require any kind of back-end processing, and is fully handled via front-end, I am unable to make it work without the use of JavaScript.
The only way would be to make it support static site generation.
Correct, it is my creation.