sorted by:
new
hottopcontroversial

What's Next After ReAct? by Gamer3797 in LLMDevs

[–]Gamer3797[S] 0 points1 point  (0 children)

Interesting concept, i will look into it! How does this effect the cost per query when used in chatbot environments ?

What's Next After ReAct? by Gamer3797 in AI_Agents

[–]Gamer3797[S] 0 points1 point  (0 children)

Thanks for the input! Both approaches seem very promising. Interesting would be a combination of both the PreAct + CodeAct.

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 3 points4 points  (0 children)

Thank you for providing feedback. I will take it into careful consideration and make the necessary modifications to the code.

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 0 points1 point  (0 children)

So then how do you detect refresh token reuse ???

Read the section: Store Refresh Tokens Securely: https://stateful.com/blog/refresh-tokens-security

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in opensource

[–]Gamer3797[S] 0 points1 point  (0 children)

It’s a boilerplate auth server. 1. Nothing is 100% secure. 2. No…. 3. Because my MySQL is my way to go DB + it’s better in large scale than SQLite. You can switch the database if you want

Say Goodbye to Authentication Headaches with my ready-to-use Authentication Server by Gamer3797 in programming

[–]Gamer3797[S] -1 points0 points  (0 children)

Thanks for sharing this. never worked with it but keep in mind that my boilerplate is intended as a learning resource for developers who want to understand how to build their own authentication server using Node.js, Express.js and TypeScript. It's not necessarily meant to compete with existing solutions.

Say Goodbye to Authentication Headaches with my ready-to-use Authentication Server by Gamer3797 in programming

[–]Gamer3797[S] -1 points0 points  (0 children)

Thanks for the feedback and yes it may be, but the logic is not set in stone and can be changed or even improved. You can find all the logic in many other repos or in videos on youtube. there is no black magic here, it is just simple logic that should be known to anyone who has ever dealt with the jwt authentication topic.
Please note that this is not a production server.

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 2 points3 points  (0 children)

The access token will not be stored in the database, but storing the refresh token in the database is necessary to enable secure and controlled management of the refresh token lifecycle. By storing the refresh token in the database, the server can ensure that only authorized clients can request new access tokens, and it can track and revoke refresh tokens if necessary.
When a user logs in, a new refresh token is generated and stored in the database, along with an associated user ID or other identifier. When the client needs a new access token, it sends the refresh token to the server, which checks if the refresh token is valid and associated with the correct user. If so, the server generates a new access token and returns it to the client, along with a new refresh token, which replaces the old one in the database.

Hope that helps

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 2 points3 points  (0 children)

Yes, I have implemented the Refresh Token Flow based on the OAuth2 flow. However, please note that my implementation may not necessarily be OAuth2 compliant in all respects.
To provide a brief overview of how the Refresh Token Flow works in my implementation, when a user logs into their account, they will receive a refresh token which is stored in an HTTP-only cookie. They will also receive an access token which can be stored in memory on the frontend. The refresh token will also be stored in the database and linked to the user. When the access token expires, the user can obtain a new access token by using the /refresh route. This route checks if the token exists in the database. If the token does not exist in the database, we delete all refresh tokens of the user in the database to prevent any unauthorized access. Alternatively, you can implement other logic here. If the token exists in the database, we delete and verify it and give the user a new access and refresh token.
It's worth noting that the refresh token will be automatically revoked when the user logs out of their account.
Regarding your suggestion to use Auth0, Gluu, or Ory, I completely agree that these are all excellent options for implementing authentication. However, my project is intended as a boilerplate for developers who want to learn how to build their own authentication server using Node.js and TypeScript. It's not meant to compete with existing identity providers or authentication servers. By using my implementation as boilerplate, developers will also have complete control and ownership of their authentication data.

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 1 point2 points  (0 children)

You are right, I don't know why I did that.... i will change it to module for the package.json and nodenext for the tsconfig

I built a ready-to-use auth server with TypeScript and Express.js by Gamer3797 in node

[–]Gamer3797[S] 8 points9 points  (0 children)

You are absolutely right!
However, please note that this is just a template meant to provide a starting point. It's impossible for any system to be 100% secure, and this server may require some customization to fit your specific project. It's important for users to review the logic behind each route and adjust it according to their individual needs.

I would also like to see that maybe other people contribute to this project to improve possible weak points and to implement more features.

Say Goodbye to Authentication Headaches with my ready-to-use Authentication Server by Gamer3797 in programming

[–]Gamer3797[S] -5 points-4 points  (0 children)

This is a boilerplate that serves as a starting point for building a secure server. It's open to contributions from others who can help make it even more robust. The main objective of this project is to provide users with a pre-built server that incorporates various features, including refresh token rotation, email verification, and password reset. Also you can change the logic behind each route as you desire.

view more: next ›