✍️ @Brian Segura's Blog

[briansegura15]

• 📰 Dec 8th have rough draft in
  • Mentor reviews by 12/15
• Dec 15th-20th turn in final draft

Title: Passport.js, a security solution for small startups and large enterprises alike.

Requirements

Questions to consider:

• Who’s reading this? Where are they in your dev journey? What do they need to know before they can dive into this story?

  • People interested in security or working/learning with Passport.js.
  • They can be anywhere in their journey because security can always be used. From your first full-stack app to enterprise-level software
  • They need to understand why I am writing about Passport.js and what it's even used for.

• If people could leave with just one action, what would it be?

  • The one action I would encourage them to take is to watch the massively long 12 hour video (maybe I wouldnt tell em its 12 hours lol) that dives deeply into passport.js and user sessions. I would do this because the mentor (Go Glenn!!) for this epic recommended it and it is where I believe the answers lay.

• Were there surprises or alternative problem-solving you want to give a heads up to?

  • This whole experience has been surprising and full of problem-solving and I love it lol.

Outline

Talking points

Why does software need security/authentication/authorization?

• Establish the specific problem the team at Amplify faced at the top of the blog and then show the solution at the bottom of the blog
• List some other security options and why Passport came out on top
• Give a TLDR of the moving parts involved
• List off a couple of the Strategies that can be easily integrated from Passport
• Mention how this was your first time contributing to open source and the pressure was on
• Explain how pressure is what makes us grow
• Reference issue/PR for photos
• Add some cool media
• Consider using text to voice. Use table of contents.

To Do: when you complete the requirements, add "outline ready" label on your issue

📰 Blog Rough draft: Format into a google doc

Questions to answer across draft

• Why is this helpful for a reader?
• What problem does this help them solve?
• What kind of experience should the reader have or that you will provide so they’re up to speed
• What larger problem is this solving?
• Were there other ways of solving this problem - what made you choose the one that you did?
• What were the positive tradeoffs? (Did it save time? Save hours? Was more secure?)
• What is the best way to present the content (i.e. code snippets, graphics) ?
• What additional resources can they provide the reader if they want more information?
• Is there a call to action?

To do: when you complete the requirements, add "draft ready" label on your issue

• intro paragraph
• context of Amplify
• paragraph on problem
• paragrph compare your solution
• paragraph impact your solution
• Less than 600 words
• Drop link to your google doc (with permissions for edits) in review issue

[briansegura15]

Hey @unnamedrd or @Alex-is-Gonzalez, I believe I followed all the steps necessary to edit the issue to submit my outline, but I still cant find a way to add the outline ready label to this. Thanks for your time have an amazing week.

[Alex-is-Gonzalez]

The outline looks great! If that 12-hour-long video helped you out, I would put it at the end for resources, or you can always refer to the video via timestamps that way your readers can skip to the insightful parts of it. I'm excited to read your blog draft!

[briansegura15]

Here is the link to my rough draft, all critiques welcome 😅
@Alex-is-Gonzalez @unnamedrd

[unnamedrd]

Hey @briansegura15 would you mind adding editing permissions to the doc please? 🙂

[briansegura15]

Hiya @unnamedrd the doc should have editing permission now 😃

[beverand]

There is a paragraph that starts with: (for this following paragraph I plan to go into further detail with my next drafts iteration)
Can you ping when you've added that detail?

[briansegura15]

Hiya @beverand I updated that detail

[beverand]

Hi Brian,
Your update to the detail is good, but do you want to be more specific than your high level over view?

1. What routes did you create? What tasks did they handle?
2. What model did you use, did you create it or was it pre-existing?
3. What was the secure hashing algo you used? How did you implement it?
4. What were the configuration settings that you used? What was the session management that you used? How did you implement it?
5. What were the middleware functions that you defined to protect the authenticated routes? What is local strategy?

How did you test these things to know that they worked?
I also did some editing of the text to tighten it up and make it more concise any changes you like you can keep, and any you don't like you can reject.

[briansegura15]

Hey @beverand I appreciate the edits! I added them accordingly.

As for increasing specificity, it is a bit difficult to get more exact due to so many dependencies on so many other issues that were not complete. Furthermore, the original issue was split between another fellow named Konny and myself, so he worked on half of this and I don't have direct insight into it.

1. There was no functionality for logging in or out so no routes were made
2. At the time of implementation, there was no admin (there is now) so I created a mock admin
3. I used the third-party dependency that is tried and true, Bcrypt
4. This is a part that my partner worked on but the session management is PostgreSQLSessionStore
5. The middleware functions were also implemented by my partner

Testing was also problematic due to so much of our code being abstracted away by packages like Passport and Bcrypt.

So for these reasons, I thought it was a good idea to have the high-level overview as opposed to trying to get way more specific.

[beverand]

Hi @briansegura15,
I'm a little confused, you didn't do the first thing on your list in the overview? So you have in your overview components you didn't create or use? What a missed opportunity for your blog to be special!
The thing about specificity is that it shows the struggle of the work that you did. When someone is working on a similar problem, they are beyond the top-level overview. It seems an amazing little nugget to know that you can still implement passport without routes.
My suggestion would be to take the numbered list of answers that you gave to my questions and put that after the overview. Talk a little bit about what you actually implemented and how it worked. This would also allow you an opportunity to link to Konny's blog.
When you say at the beginning of your blog "I’m hoping that my first issue in open source will help you solve some of yours", what would a person be struggling with to make this actually true? When you say that, it sets expectations, and you actually have the content to meet that.
I want to make sure that you have options here, so if you feel like you don't want to make anymore changes to it, you can leave it as it is.

P.S. I did see two more grammar things, you can keep or reject changes on.

[unnamedrd]

@beverand @briansegura15 Thanks everyone for the work on this!

Brian thanks for all the hard work on this and Beverly thanks for the thoughtful edits. Generally, we limit edits to 1 round. Submit the rough draft -> get the feedback -> make any edits for the final copy. Something to keep in mind for the future. Any suggestions given should be encompassed in the first round of feedback. For writers, time is always limited, and we're not striving for perfection, we're striving for done. I think this blog is done and done well. :-)

Thanks for the team work everyone!

[beverand]

Sounds good!

…

On Wed, Jan 31, 2024 at 7:04 PM Naj ***@***.***> wrote: @beverand <https://github.com/beverand> @briansegura15 <https://github.com/briansegura15> Thanks everyone for the work on this! Brian thanks for all the hard work on this and Beverly thanks for the thoughtful edits. Generally, we limit edits to 1 round. Submit the rough draft -> get the feedback -> make any edits for the final copy. Something to keep in mind for the future. Any suggestions given should be encompassed in the first round of feedback. For writers, time is always limited, and we're not striving for perfection, we're striving for done. I think this blog is done and done well. :-) Thanks for the team work everyone! — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZUG6VH2S4IGI6HQLJCBCLYRMA2LAVCNFSM6AAAAABAGBXMASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRQGQYTEOJVGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[briansegura15]

Hey @beverand, yeah many dependencies from other issues and entire components/pages were nonexistent, things that were needed for this integration to be wired complete. The struggle was definitely real thinking about Passport in an even more abstract sense since we were essentially getting passport ready to be added to the project without the project being ready to have passport received.

But I appreciate you, just from the detailed response I can tell you're someone with great experience, and having someone who pushes people to dig deep and deliver better work is always welcomed on my part.

@unnamedrd and gracias amiga! Thanks for this amazing experience.

Now that I have added the revisions how do I proceed from here?