Hi
I'm Stefan, Maker of Full-Stack Developer Job and Resume Board.
I started my project on February 19. You can read a bit more about here
All started with a simple listing of Full-Stack Developer Jobs. A second step was a simple Job Newsletter Subscription.
After I did some improvements I saw/got from User Feedback, Usage Analyses etc, like better Filter Options, improved Job aggregation etc.
Then about a month ago, I release the Online Resume Builder for Candidates, also with following improvements, like privacy Settings, Contact possibility via Form for Recruiters etc. You can see a bit of the status from back then in this video
So you can see, I deliver continuously new features for the user and improve on backend side things, which I see make sense to automate.
End of last week I released an advanced Job Alert and Newsletter Feature, where Candidates for Full-Stack Developer Jobs can define multiple Filter based Subscriptions for daily/weekly Job Newsletters and Job Alerts, send as soon a new Job is added to the board:
Now... What I did only over this weekend is a "Password Reset" Feature.
Ok, there are frameworks where you have this together with Auth etc out of the box. I use Go and no framework and do this all on my own, mainly for flexibility reasons and it's good learning.
But why I did it so late? Well. Makers do things then when they are bringing some value for the product and the users who use it. As long as I did not have much registered users, there was just no need for this. If a User forgot his PW, i set him a new one manually (or I could, it just never happened).
But now, with the new features, I have over 200 Users and growing, so I want to give this feature out to the users and also make my life potentially easier. :-)
edited:
The point is NOT to let security or other important stuff left behind, but features, which are not that important to a user or not bringing any other gain to the product. So in the mentioned case of "Password Reset Flow", this does NOT mean, that passwords are not stored securely, but there were no UI and API endpoints to do so.
Cheers
Stefan, Maker of Full-Stack Developer Jobs and Resume Builder
Latest comments (5)
yeah, that's exactly the point.
Sounds familiar. Also working on a service and the reset password flow is actually the last thing to do before putting it live. In my experience it's not really necessary during a beta/alpha period with a few users, as you just want to test out the features your service is about 👍
I can only agree :-)
"I set him a new one manually"
If I read that, I always am afraid that security is breached by not hashing and salting the passwords, please tell me you do that though. Additionally, while I agree it offers more flexibility by using no framework, you do sacrifice the built-in security components in frameworks such as CSRF and session hijacking. Even when you use a framework, you do have to be wary about security. For instance, a lot of frameworks do not throttle requests which could result in brute force attacks and such.
I really like to work with security concepts, so that is why this comment is so security oriented.
Thanks for your comment Wesley.
Well, my post or way of doing this kind of project is not about sacrificing security needs. I would say, that having a PW Reset Flow does not mean, that things are more secure, with or without a framework. Of course, always having in mind, that eg saving a PW need some hashing and salting, as you 100% correclty said. Don't worry, I never would save a PW without that, manually or implemented. :-)