Bro, please can you make full fledge full stack rust in backend project because every full stack present in mern or java not in rust, we need some basic, or advanced full stack projects with best practices, it's just a recommendation. Great to see a person contributing to rust.
Thank you so much for the suggestion! 🙌 I really appreciate your support. A full-stack Rust project is a great idea, and I’ve been considering doing something similar. While MERN and Java are more popular in full-stack development, Rust is quickly gaining ground for its performance, safety, and concurrency benefits. Frameworks like Axum, Rocket, and Actix make it a solid choice for building scalable backends. Plus, Rust-based frontend frameworks like Yew are emerging, and combining them with modern frontend tools like Next.js or SvelteKit can create powerful full-stack applications. I’ll definitely work on this series to showcase the full potential of Rust. Stay tuned! 🚀
Cool video. Thx. I don't like JWT. We need an identifier for what the token represents, such as a username or e-mail, expiration time, signature with a global salt/key and a per-user salt/key like in classic PHP frameworks. Authorization should be handled at the transaction level, or close to it.
Thank you for watching and for your feedback! I'm glad you enjoyed the video. I understand your concerns regarding JWT. While JWT is widely used and offers stateless authentication, it's true that there are some trade-offs, especially in terms of security practices like using global and per-user salts, which some frameworks implement for more secure token handling. I appreciate the suggestion about handling authorization at the transaction level-it can definitely add an extra layer of security. I'll consider covering more advanced techniques for token handling and authorization strategies in future videos, including approaches inspired by classic frameworks. Thanks again for your thoughts, and happy coding!
Thank you very much for your comment. There are a few things I don't understand (or never heard of): - "need an identifier for what the token represents": so you meant that in 1 app, the jwt content formats in different requests can be different? - "signature with a global salt/key and a per-user salt/key": why can't we have this with jwt? Current jwt libraries might not support this yet but we can do it, right? - "Authorization should be handled at the transaction level": could you elaborate it or give some examples?
Thanks for your thoughtful questions! I'll try to clarify each point: "Need an identifier for what the token represents": Usually, in JWTs, we use a consistent identifier like a user ID, email, or username. This doesn’t typically change between requests, but theoretically, you could design tokens with different structures for different request types (though this isn't a common practice). The important part is that the token carries enough information to identify what the token is representing (like user data). "Signature with a global salt/key and a per-user salt/key": You're right! JWT libraries don't usually offer this out-of-the-box, but you could implement it. You'd use a global key to sign the JWT but could add extra layers of security by incorporating a user-specific key or salt during the signing process. This approach adds complexity but could make token signatures unique per user, enhancing security. "Authorization should be handled at the transaction level": This refers to checking a user’s permission for each specific transaction or operation rather than just relying on the JWT claims. For example, before allowing a user to perform a sensitive action (like updating data or transferring funds), the system would verify their role or permission for that specific transaction. This is a more granular and dynamic approach to authorization, making it more secure. I hope this helps! Feel free to ask more questions if you’d like further clarification. Happy coding! 😊
Bro, please can you make full fledge full stack rust in backend project because every full stack present in mern or java not in rust, we need some basic, or advanced full stack projects with best practices, it's just a recommendation. Great to see a person contributing to rust.
Thank you so much for the suggestion! 🙌 I really appreciate your support. A full-stack Rust project is a great idea, and I’ve been considering doing something similar. While MERN and Java are more popular in full-stack development, Rust is quickly gaining ground for its performance, safety, and concurrency benefits. Frameworks like Axum, Rocket, and Actix make it a solid choice for building scalable backends. Plus, Rust-based frontend frameworks like Yew are emerging, and combining them with modern frontend tools like Next.js or SvelteKit can create powerful full-stack applications. I’ll definitely work on this series to showcase the full potential of Rust. Stay tuned! 🚀
Thanks
Cool video. Thx.
I don't like JWT. We need an identifier for what the token represents, such as a username or e-mail, expiration time, signature with a global salt/key and a per-user salt/key like in classic PHP frameworks. Authorization should be handled at the transaction level, or close to it.
Thank you for watching and for your feedback! I'm glad you enjoyed the video. I understand your concerns regarding JWT. While JWT is widely used and offers stateless authentication, it's true that there are some trade-offs, especially in terms of security practices like using global and per-user salts, which some frameworks implement for more secure token handling.
I appreciate the suggestion about handling authorization at the transaction level-it can definitely add an extra layer of security. I'll consider covering more advanced techniques for token handling and authorization strategies in future videos, including approaches inspired by classic frameworks.
Thanks again for your thoughts, and happy coding!
Thank you very much for your comment. There are a few things I don't understand (or never heard of):
- "need an identifier for what the token represents": so you meant that in 1 app, the jwt content formats in different requests can be different?
- "signature with a global salt/key and a per-user salt/key": why can't we have this with jwt? Current jwt libraries might not support this yet but we can do it, right?
- "Authorization should be handled at the transaction level": could you elaborate it or give some examples?
Thanks for your thoughtful questions! I'll try to clarify each point:
"Need an identifier for what the token represents":
Usually, in JWTs, we use a consistent identifier like a user ID, email, or username. This doesn’t typically change between requests, but theoretically, you could design tokens with different structures for different request types (though this isn't a common practice). The important part is that the token carries enough information to identify what the token is representing (like user data).
"Signature with a global salt/key and a per-user salt/key":
You're right! JWT libraries don't usually offer this out-of-the-box, but you could implement it. You'd use a global key to sign the JWT but could add extra layers of security by incorporating a user-specific key or salt during the signing process. This approach adds complexity but could make token signatures unique per user, enhancing security.
"Authorization should be handled at the transaction level":
This refers to checking a user’s permission for each specific transaction or operation rather than just relying on the JWT claims. For example, before allowing a user to perform a sensitive action (like updating data or transferring funds), the system would verify their role or permission for that specific transaction. This is a more granular and dynamic approach to authorization, making it more secure.
I hope this helps! Feel free to ask more questions if you’d like further clarification. Happy coding! 😊
Thompson Anna Lee Michael Martin Margaret
5 hours with no chapters is rough.
Thanks for the feedback! I've just added chapters to make navigation easier. You can now jump to specific sections of the video! 😊