I really dislike having to watch an entire video to catch the one bit of useful information. I wish I had the time to watch entire videos, but honestly, I don't. On top of that, my brain has often wandered off well before I get to the interesting bit.
Oh wow, I didn't know this existed. A little bit thin on the information, but better than nothing. I also want to look at the new capabilities of the Gemini model to help me create blog posts from my videos.
Kind of horrible timing, as Apple will disable PWAs in the next iOS update for the EU. Kind of crazy, but I guess they will get punished for this behavior. So let's hope this will be reverted soon...
Any field in a DB can be vulnerable to SQL injection. Filtering out characters is a terrible way to mitigate that attack, you should be using prepared queries where it does not matter what chars you have in your username or password. You should never form a query with string concatenation.
You may want to limit chars in a username to ones allowed in URLs (or even ones that don't need escaping) if you ever want it to appear in a URL though. Or any other places the user name might be used, but a entry in a DB should not matter.
There are a lot of edge case characters around visually indistinguishable names. If that is a concern usernames should use a restricted known character sets instead of trying to block specific characters. You likely should also treat lookalike characters as equivalents when checking for username overlap.
Since character filtering is all about edge cases, I would like to note that if someone uses an FF14 character name as a display name, the game allows for apostrophe and hyphen and will have a single space.
It's not a huge edge case population wise (unless you're building an application focused on that community or genre), but as others have said it's much safer to prevent the injection from happening in the first place using an interface rather than try to figure out all the way a user can break out of a constructed string.
You don't need to escape any content for storing in a DB field.
Use the correct database interface and you're good.
I'd be more concerned about intention and intentional design. Arbitrary characters can be misleading or problematic for users. Using an allow list for accepted username characters is a good approach if you can't depend on good intentions of users.
Looks pretty good. I could use it to rebuild my simple HTML and CSS only webpage. Having a lot of HTML files that you have to modify manually every time you want to update them is pretty boring and exhausting.
More important than learning a framework is to learn how things work beneath the frameworks. Try doing a project without frameworks. Who knows. You might even like it.
I'm glad this style of frontend coding (where you use a prebuilt JS library that handles common interactions through simple configuration, rather than writing custom JS) is coming back into fashion. It was common 15-20 years ago, and as web apps became heavier and heavier, I started to think it was a good idea again.
Bun is designed as a drop-in replacement for Node.js. It natively implements hundreds of Node.js and Web APIs, including fs, path, Buffer and more.
The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity.
If it can replace node and pnpm at the same time then this sounds quite good actually.
While Vite currently works with Bun, it has not been heavily optimized, nor has Vite been adapted to use Bun's bundler, module resolver, or transpiler.
So it can also do tooling like vite but it primarily aims to replace node as a better and faster js runtime since they're rewritten most js api in zig and c++ from what it shows on their github. I'll give it a try sometime and see if it's really all that fast and easy as it claims.
I still can't get to grips with the islands directory causing separation from my other components, it feels weird because both islands and components are components, I think Next.js' approach of having a use client string at the top of the interactive component makes much more sense because your component directory structure can mimic the app/pages directory layout.
Honestly it's the only thing keeping me from jumping over to Fresh.
HTTPS is already end to end encrypted. It's literally what it's for. TLS is everywhere: SMTP/IMAP (emails), even OpenVPN.
What about it are you trying to improve on? There ain't much you can do on a website, if the connection is intercepted then everything falls apart because the attacker already has the ability to modify whatever your server is sending, so any encryption you'd do in JS is compromised before it even runs.
If you can make an app, then you can do something called certificate pinning which effectively gives the client the public key of the server to expect. It guarantees that the client will only talk to the right server, and if that is broken, then literally everything is broken and nukes are probably about to get launched.
Most encryption uses the same primitives: RSA/ECDSA/DH to derive a stream cipher and then it's pretty much always AES these days, or sometimes ChaCha20, and usually SHA1 (broken) or SHA256 for message authentication.
E2EE makes senses when you're building say, a messaging app. There the E2EE is that the user's device holds the keys, so even the server can't see the message even as it stores it and sends it to the other device.
I may at times only have access to HTTP only (No HTTPS) which is one of the reasons why I want another form of encryption.
Encryption with most VPNs are more secure than HTTPS. Yes, the connection between the VPN server and the web server is not encrypted with the VPN and only HTTPS. However the encryption between the VPN and personal device is superior, not because it is relayed. My understanding is that HTTPS is "secure" for basic use, just like Windows 11 is secure. But not secure from five eye agencies unlike VPNs and other like systems like Tor and I2P.
My goal is to have a user connect to a web server and have it not possible for the web server to know what is going on, nor can anyone snooping the packets in transit know what is going on. Not know the HTML structure, form field data, etc.
And you cant use self signed certificates because?
They provide the same level of encryption. The benefit of a domain and a trusted CA issued cert is that browsers/os will automatically trust that the server is who its said it is (ie you dont get a warning).
But if you import your servers root CA to your OS, then your OS (and browser) will automatically trust any cert issued using that root cert, thus you dont get a warning.
With or without a warning, it will still encrypt at TLS1.3
Web Development
Active