Articles on sharmaaditya570191's Blog

From console.log to GSoC 2020

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 31 Aug 2020 20:51:29 +0000

It is time to share my wonderful journey to Google Summer of Code, tips and tricks to get selected and what all you can do before GSoC to take a step closer to your dream internship or job.

I have written in detail about my journey here - https://medium.com/@sharmaaditya570191/from-console-log-to-gsoc-2020-1a6e9dc2334e

Thank you EOS Design System and Python Software Foundation for this awesome opportunity.

Signing off!

Final touches, Bug Fixing and last week nostalgia

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 24 Aug 2020 18:17:30 +0000

This is officially the last working week of Google Summer of Code 2020. This was one of the best experience of my life. I learnt a lot of new things. I saw my knowledge and technical skills growing exponentially with every passing week. I mastered the art of collaborating in a team and drawing inspiration and motivation from my hard working mentors and project partner.

This week I fixed various client and server side issues related to the authentication system and the states depending on it.

I spent time on making a final report for my project to identify the features we have completed. I also wrote about some interesting new ideas that can be added to our user story system.

I will always be a part of my awesome organization and would keep contributing.

I have published my report here - https://gitlab.com/sharmaaditya570191/gsoc-2020-project-report

Inches closer to the GSOC’20 finish line

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 17 Aug 2020 18:10:47 +0000

Our sweet GSOC family literally coded the summer away with some of the best developers from around the world always ready to hold our hand in case we loose balance. Now the hardest week has come. Its time to say goodbye and I am not able to get over it. The end is getting closer as you read this but my heart is not designed to close the best doors so easily. My brain is full of brand new ideas to implement after the GSOC timeline. For now lets check out my latest patches which got merged this week.

What did I do this week?

We made a decision that we should polish and test the existing features before adding new ones so that we can find and fix bugs if any.

Result? We ended up making a list of 13 bugs. 😂

User authentication was the first thing I completed but I could still access the protected routes in the UI although some of them were not working because of the absence of the JWT token in the cookies. Still we had to maintain the user session on the client side as well.

I created a global state using createContext in React so that we can update the state when the user logs in to our system. I allowed users to access the protected routes by checking against this state. Users would be redirected to the login page in case they are not authenticated. Solved?

Not yet. Another corner case got us thinking. If we reload the page then the state is lost and user is logged out. It would be a terrible user experience to force the user to login every time they may refresh the page because of connection issues on their side.

This time I stored the state in localStorage so that we can save state across page refresh. Security was maintained by our httpOnly cookie.

This was solved but now users could vote more than once. Imagine allowing this in real government elections of your country.

Result? You may get the same president every time. 😂

Everyone may not like that right? (Trump smiling secretly 😝)

This was a simple fix by introducing a new state variable and updating it if the user has already voted for a story. You press again and your vote gets removed.

My mentor and I spent some time in trying to fix our httpOnly cookie attributes to work with the latest updates in Chrome. However, none of our solution worked in Chrome because Chrome was probably upset with us and did not set the sameSite attribute of the cookie to none.

We ended up creating a new sub-domain for our server so that the request is no longer a cross-origin one. 😂

Now some smart users were able to edit stories of others. Imagine editing and filling your friends stories with shit. 😂

Devesh (my awesome GSOC partner) saved all F.R.I.E.N.D.S here by updating the client side with a minor fix. Thankfully our server did not betray us here.

Then came my killer move. A full end-to-end test. Yes, I was able to complete a long test in Cypress to test all our main functionality like login, home page, creating new stories, editing them, commenting and even replying on comments. This will save a lot of time in the future by eliminating the need of manually testing all functionality before merging every patch. We may also consider running this test in the CI soon.

What is coming up next?

This is officially the last week of GSOC’20. I will make a final report for my project and get it reviewed from my awesome mentors.

I will extend my Cypress test to cover signup, notifications and logout functionality.

Finishing touches also make a great impact. I will add some decorations for the final celebration and release to production (heaven for developers). 🎉

Did I get stuck anywhere?

I firmly believe that as a developer if you are not stuck then you have not seen enough.

Some corner case bugs were a pain point. I also got stuck when trying to handle multiple cases for filters and pagination. It was a bit tricky to identify the points of optimization for enhancement of user experience but that gave me the real development experience. 🙂

My never give up attitude helped me to fly high above all obstacles to fix all bugs we identified till now.

Time flew and brought us close to the end. I honestly hate saying that and decided not to say a goodbye. Its that simple. Sometimes the best things deserve to be a special part of your life and EOS had already made its place in my heart long back. Loads of 💖 to my EOS family.

Cheers to a new beginning. Its not the end.

Signing off. Aditya Sharma.

Pagination, Privacy Policy, Bug Fixing and Testing in the User Story system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 10 Aug 2020 16:38:48 +0000

I started this week with a heavy heart. I entered the last coding phase of the best experience of my life. I made my mind that I will keep contributing to this project and organization and make the most of this awesome learning opportunity. I will not let it end here. I can already imagine a smile on my mentors face as they read this. You are the best people I have ever met and worked with. Now lets jump to my magic work. :)

What did I do this week?

“Many solutions will work but keep solving the problem till you optimize it and reach the best possible solution.” I do not know which genius said this but I my mind got stuck with this and I decided to spend some time to add pagination for our beloved users. This means users can reach any page with a click and we do not have to load all stories in one go. Imagine our free Heroku servers burning on hitting the API to load 500+ stories in one go. LOL!

The most important thing before going live was telling users how we are going to use their data. I worked on the privacy policy page and created a new model in the back end so that admins can manage its contents and update the privacy policy when needed.

This also means that we have to notify users of a privacy policy update. I wrote a custom lifecycle hook in Strapi which automatically creates a notification when the old policy is deleted and a new one is created. This special notification is displayed as a popup modal on the home page for users who are already logged in. They have the option to accept the new policy. If they do not accept then they can continue using our system but are logged out. This means they can only read existing stories.

New users will not see the modal as they can access the updated policy when they register into our system.

After pushing these heavy changes to production I fixed some bugs related to the my stories page and pagination not working along with product filters.

Finally I studied Cypress docs for some time. I set up Cypress for our client side so that we can write, run and debug tests easily.

What is coming up next?

I have identified some bugs on the client side and I will spend some time to fix them.

I will try to give the remaining time for writing tests as they are really important to future proof our application.

I have a lot of exciting new features in mind like Slack integration, email notifications etc and I will add them only if time permits.

I understand that the best things take time and patience and I will keep adding a thousand more features to user story even after GSOC. :)

Did I get stuck anywhere?

It is natural to get stuck while trying to do the best things.

I got stuck at multiple places while trying to make the pagination feature work along with other filters. Covering all possible cases for the privacy policy model was also a bit tricky. Discovery of new bugs might be a bit easy but they can be difficult to solve. Cypress and software testing in general was absolutely new to me.

I do not give up easily and kept trying to overcome all obstacles by the end of the week. All my efforts were really worth it. I learnt a lot.

I am also blessed to have such awesome mentors for support and motivation. They work really hard everyday and I learn a lot just by observing them. :)

Lifecycle hooks, threading and notification system in the user story system in GSOC'20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 03 Aug 2020 18:16:09 +0000

A whole new set of awesome features are here for our beloved users. Do not get worried by the heavy terms in the title. Sit back, relax and follow me to catch a glimpse of my implementation for giving you the best possible user experience. You will soon be able to write your own story, share with us how you use our products, relate to other users’ stories, vote them up and we’ll make sure we deliver cohesive solutions to you.

What did I do this week?

This week it was time to design a personalized notification system for our users to notify them about the latest features when we launch them. Only author and followers(users who have voted) of the launched story should receive the notification so that we do not disturb other users who might be busy writing their own amazing stories.

The admins update the status of a user story to “launched” via the back end Strapi panel when our team have successfully pushed a new feature to production.

Now Strapi lifecycle hooks come into action. The lifecycle hooks are functions that get triggered when the Strapi queries are called. They will get triggered automatically when we manage our content in the Admin Panel or when we develop custom code using queries.

I wrote a asynchronous afterUpdate hook in the user story model which checks if the status of a user story has changed to “Launched” after being updated. If the status has changed then it creates a new notification record on the server with a custom message, seen status, link to the story page and a list of users to whom the notification is to be shown. I did this by utilizing Strapi services which are a set of reusable functions. They are particularly useful to respect the DRY (don’t repeat yourself) programming concept and to simplify controllers logic. Every notification on the server is required to have a different and unique message.

On the client side I fetch the notifications for the particular authenticated user using GraphQL queries. When the user has seen the notifications then they are marked as seen on our Strapi server too. This is done using GraphQL mutations which update the status of a notification. I made sure that we do not hit our API multiple times to update the status of a notification.

The next major feature of the week was to add threading in comments. This allows users to reply to a particular comment on a story in a thread. I created a separate model on the server for user story comment replies. Each comment reply belongs to one comment, a user can have multiple comment replies, each reply belongs to one user and one comment can have multiple replies. Such was the complexity of relations between the models schema. You can also see the number of replies and even add your own reply via the client side.

All these extra efforts will make your user experience super smooth. The blazing fast React re-renders and updates on the client side will be a icing on my cake. :P

What is coming up next?

I will spend some time to polish and test the existing features.

I will also work on the user story privacy policy to allow admins to manage and update the policies from the admin panel. Users should receive notifications whenever the privacy policies are updated. The user can then choose to accept them or remove their account.

Did I get stuck anywhere?

I got stuck at multiple places be it writing hooks and custom controllers in Koa for my server or implementing mutations in an effective and optimized way on the client side.

However, I did not give up and kept reading more about the topics and technologies involved. This way I was able to learn a lot of new things during the week. Debugging and troubleshooting became super easy after I hit my learning goals and covered all basic concepts properly.

This ended the week with the second evaluation. I received a really nice feedback from my mentors. I expressed my sincere thanks to them today for always supporting, motivating and inspiring me to learn more.

Boosting application security, voting and commenting in the user story system in GSOC'20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 27 Jul 2020 18:10:58 +0000

This time I let the title reveal the much awaited features that are up and running by the time you read this. I am really excited to experience that adrenaline rush when I get a chance to vote in the real elections and choose our leaders of tomorrow. For now I can fulfill my desire by contributing in selecting the best and most wanted user story of the season. Follow me to understand how I solved the mystery of votes and relations.

What did I do this week?

Recall that complex bug where Strapi could not find the schema for our user story model and kept flashing that weird error on my terminal despite repeated attempts. This time I dived deep inside to catch a glimpse of the internals of Strapi and finally solve that.

The fields of the newly established relations in the user story model were overlapping with each other because Strapi does not drop or migrate the database when a model is deleted or updated. They do so because users may start their application with a production database and a model name may not match with one of the tables in the database. Crash! :/ This is a work in progress and Strapi is improving it. I solved it by choosing a different one sided relation type of one-to-many and renamed it to followers.

Now I added client side logic for the voting system so that a user cannot vote more than once. Clicking on the like button for the second time removes the vote of the user and so on. Pushing all this to production gave me a sigh of relief. :)

After a deep breath I moved on to allow users to leave their valuable feedback and suggestions on user stories. Yes, comments. This way we can take into account the views of more users and design our next awesome feature accordingly.

Now it was time to step up the security as a lot of functionality was already in place. I wrote a custom controller in Koa which checks that the localStorage id matches with the id of the authenticated user and if the same user is the author of the story they are viewing. A positive response will allow the user to edit their story. I also modified the controller which creates a new story and now it can automatically assign the authenticated user to be the author of the story.

What is coming up next?

I will work on the notification system. It would be great to have three types of notifications — in app, push and email notifications.

These will notify the user story author and followers that their user story has been launched. Only organization admins can update the status of a story from the Strapi panel.

If time permits I will try to setup Cypress for testing our application.

Did I get stuck anywhere?

The React implementation to allow one time voting for each user was a bit tricky as there are a lot of state variables on our story page. However, I solved this by catching the previous state value by applying functional updates in my useState hooks to overcome the stale state problem which arises due to closures in React.

Writing controllers for my server in Koa was also new but I was able to learn the basics quickly as it is similar to Express.

This ended the week on a sweet note. Stay tuned and get ready to receive another set of notifications on your device. Do not worry. We will not throw those sales ads on you again. This time it will be about the launch of your own story. :P

Making and inspecting model relations for the user story system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 20 Jul 2020 17:20:25 +0000

The world is full of relationships. Everything around us is connected to each other in some way or the other. Sometimes relations can be hard to figure out. Join me as I help you create a unique relation with our user story system and some of its brand new features.

What did I do this week?

This week started with full action and thrill as usual and we decided to modify our models to align with our product name. This means all existing models had to be renamed according to the user story theme on the server side. A rename operation seemed like a small and simple task but I soon realized that Strapi does not update the GraphQL schema if we rename a model. This is because existing tables are not deleted or dropped from our MongoDB database and instead new ones are created. This started breaking everything on the server side.

I rolled back and created new models for user story system and imported all data from our staging database. This time the shadow CRUD functionality generated a perfect new schema for my use case. Server was good to go.

The schema changed so the next task was to change all GraphQL queries and mutations on the client side and align them with the new user story models. The docs for the schema helped me to complete this with ease.

Next I created a new model for all the products at EOS and related it to the user story system model. This allows users to filter stories according to the product and enhances user experience by allowing them to navigate faster among hundreds of user stories. I worked on the filter feature on the client side to fetch all products and filter them according to their status and product selected by the user via a drop down.

I eagerly wanted to allow users to respond to some amazing user stories so I moved on to implement the voting feature. This allowed users to vote for any user story to express their interest. Wait. It just sounds easy but some major problems and bugs were waiting for me at the end of the week before I could push the voting system to production.

MissingSchemaError: Schema hasn’t been registered for model “user-story”

My terminal kept flashing this message as I tried to figure out the problem in my new user story vote models and relations. It is still a mystery though because the same relations work fine with my comments model. I told you relationships can be hard sometimes. :/

What is coming up next?

I will work on the voting system for user stories. This involves establishing proper relations between the user story and user models. The mystery will be solved soon.

Further I would try to think of a nice implementation for the user notification system to tell users that their wait for the next awesome feature is over. This would be implemented later this week. Users really want to make comments so lets give them that privilege first.

Did I get stuck anywhere?

MongoDB relationships represent how various documents are logically related to each other. I faced a weird problem when I was establishing a one-to-many relation between my user story vote, users and user story models. MongoDB could not identify the schema for my user story model for some reason and kept throwing an error. The bug came to us at the end of the week and I am still trying to solve the mystery with my mentors. Moving forward we created a map of all our relations to get a nice picture of all relationships and find the conflicts and resolve them.

This ended the week with lots of rain which gave me some relief from the scorching heat. Stay tuned as I solve the mystery behind relationships and add new path breaking features to the user story system. The adventure is yet to begin. :)

Comment queries and edit mutations in the feature request system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 13 Jul 2020 15:09:39 +0000

Sometimes we are not able to express all our thoughts and ideas in one go. A great idea may strike later or you may want to comment and give some suggestions and feedback to stories of other users. Come explore with me some exciting features that I added to our feature request system using Strapi , GraphQL and React this week.

What did I do this week?

A strange bug starts the week with some thrill and action. Our whole application breaks when a user logs in to the system and submits a new user story. Crash!

We were checking and dividing our user stories on our client side according to their current status. No status gets assigned by default to a new user story as that is an admin or root level permission feature. In Strapi I cannot assign a default status to a relation type field because relations between models can be of various types. I solved the bug on the client side by assigning every new user story a status of “Under Consideration” in my GraphQL mutation.

A user may want to check out their own stories at some point of time so I implemented a GraphQL query to fetch all user stories based on their user id. Users need to be authenticated to access their own stories. They can check their stories for status updates, votes, likes and comments from other users.

The next was the most awaited feature of allowing our beloved users to edit their own user stories. However, they cannot change the already added description. Content can just be added to the existing information. This is just to avoid trolls. :P

What is coming up next?

This week I will create a product model so that we can relate all our products at EOS Design System with a separate user story system. Users can filter their stories for different products.

I am also working on user comments system so that we can display all comments properly and further allow users to add more comments.

Did I get stuck anywhere?

Development without getting stuck is no fun. We learn fast from our mistakes. Initially I was happy to complete the edit story functionality and it worked well. Then my mentors could hack into the system easily. Security compromised. :P

They could edit stories of other users as well after writing into the famous localStorage . I solved the bug easily by implementing a function to verify and allow editing only if the user is the owner of the story.

This ended the week on a sweet note with quite some features added. Stay tuned for more fun and action. :)

Unleash content with Strapi and GraphQL in the feature request system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 06 Jul 2020 12:12:08 +0000

You definitely received exactly what you wanted and you enjoyed using it. Now you just want to know how this actually works under the hood. Is it real magic? Did god just shaped it according to your needs and sent it down from heaven? Come with me and I’ll answer all your GraphQL queries.

What did I do this week?

It took me some time to realize that GraphQL is not another programming language. It is a specification or a technical standard. This mean it can have several implementations and variations. GraphQL.js is the JavaScript reference implementation. Legends like Strapi implemented a fully customizable GraphQL plugin which creates a new endpoint /graphql and the GraphiQL interface. The plugin adds a new layer to easily request the API using GraphQL, without breaking the existing endpoints.

GraphQL secures all queries by default and the plugin plays well with the users and permissions plugin. When we are making a query with GraphQL we are hitting the same controller’s actions as we were doing with the REST endpoints.

I utilized the introspection system of GraphQL to fetch all categories available to our user while making a new story.

I also used a mutation to create a new user story which takes in all data entered by the user as parameter. I pass all my GraphQL queries through a set of custom policies before they hit my custom authentication controllers in the customized Strapi back end. This completed the feature to create a new user story.

On the server side I created a new model for the comments on the stories which contains 3 fields. The first is a rich text field to write the comment and the remaining two are relation fields with user and feature requests models. This means I also had to add a relation field to the feature request model to connect it with my comments model.

The next big feature of the week was to add functionality to display all stories on the home page according to their current status. The shadow CRUD feature of Strapi GraphQL plugin automatically generates the type definition, queries, mutations and resolvers based on our models. The feature also lets us make complex query with many arguments such as limit, sort, start and where. This helped me to implement a GraphQL query to fetch the required details of all user stories and sort them according to the highest number of votes and most recently created stories. I used the query response to display the title, description and the no. of votes and comments for all stories on the home page.

All these features for the week helped me to catch up with GraphQL really fast. It was completely new to me and I was feeling stuck just a week before. Now by the end of the week I am happy that I am able to understand how it works so efficiently deep down the layers.

What is coming up next?

I will work on displaying all information about each user story on a separate page. This requires a query to fetch all story details by the story id. The date of publishing and author details will be available on this page as well.

The system needs an edit feature which may allow our beloved users to add information to their story. They will not be allowed to edit the existing description though.

Did I get stuck anywhere?

Sometimes rare bugs can be difficult to catch and you may feel stuck while trying to solve them. This week I came across something strange.

All my code and functionality was running successfully on my development environment. After getting merged, the Gitlab CI deployed it to our staging servers and the whole application crashed, both the client and server side.

I finally solved all bugs and got to learn that Strapi stores all the roles and permissions that we assign to our users in the database. In this case our development and staging servers are using different database. Simple :)

We just exported all our models data from the testing database to the one used by our staging server.

Another bug was to specify the exact cors origin which can access our server as I used withCredentials : true in my Axios configuration to store the cookies in the browser and send them back in future requests.

This ended the week with the first evaluations in which I received an awesome feedback from my mentors and passed with flying colors. I thanked them for all their support and guidance. Looking forward to a great journey ahead :)

Magic with Strapi and GraphQL in the feature request system in GSOC’20sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 29 Jun 2020 08:04:35 +0000
It is a dream come true situation when you get exactly what you want, neither more nor less. This also gives a sense of satisfaction and fulfillment. You already know what I am talking about. If you feel lost by now then either you are not a GraphQL fan or you are not aware of real magic. Follow along to catch a glimpse of GraphQL in action with Strapi.
What did I do this week?Users can register, login and logout from the feature request system by now. Some forget passwords really quick. I have got you covered. You can now reset passwords with a click. Now users would like to move on to ask for a new feature they really want to see. This demands an engaging interface where we can really engage users to fill in their needs.
We are almost there. I completed client side implementation of the new request components along with Devesh (my awesome gsoc partner). My Strapi server includes a field for description of the feature requests which has a type of rich text. Here is where I thought of using the same rich text editor React component which is used by Strapi.
Strapi internally builds on top of Draft.js , an open source rich text editor framework for React . This gives birth to the Wysiwyg component (what you see is what you get). I could not reuse the exact same component as we wanted to allow for least text editing features to maintain consistency while displaying the requests and eliminating unnecessary pre-processing. I ended up using the ckeditor API to come up with a custom editor which fulfills all our needs and use cases and provides basic formatting features as well.
Next was my brief encounter with a beast, GraphQL. APIs generated with Strapi are, by default, REST APIs. The idea with the famous GraphQL plugin was to add a new layer to easily request the API using GraphQL, without breaking the existing endpoints. I had to fetch various feature request category names from my Strapi GraphQL server to fill the drop down in the UI with the available category values. GraphQL allows us to fetch exactly what we need with queries. I used Introspection feature of GraphQL here to examine one specific type.
The last thing was to implement a drag and drop component which can show a preview of the image files added without interacting with the server. I will explain the implementation in detail in my next blog post in this series.
What is coming up next?I will complete the logic to connect the new feature requests page to our server so that it can be pushed to our staging environment.
I will also try to come up with implementation to display all the feature requests on the client side after fetching some specific fields using GraphQL from our server.
Did I get stuck anywhere?I am quite new to GraphQL so I faced some problems while trying to fetch data from the server. The concepts and syntax are really new to me but I will be good soon after I complete some reading and self study. I experimented with the playground to come up with the type introspection to solve it.
I was also stuck when I tried to display previews of images which were being added via the drag and drop interface. However, it was a minor problem with my JavaScript function and I could solve it quickly.
This ended the week with some really nice news for me on the professional front. I will share it soon in my next blog. Stay tuned as I come up with some exciting features involving extensive use of GraphQL queries and mutations.

Diving deep into Strapi to build the EOS feature request system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 22 Jun 2020 08:02:41 +0000

Hola a todos! Give me company as I explain to you the internals of Strapi and how I am using various mechanisms to implement custom and secure solutions for our feature request system. Grab your drink, sit back and relax as I walk you through the details.

What did I do this week?

Strapi is the magic behind our awesome applications at EOS. It is the leading open-source headless CMS. It’s 100% Javascript, fully customizable and developer-first.

This week I completed user authentication and authorization to our system. This includes register, login, logout, forgot password and reset password functionality. Lets have a look at how we can do this with Strapi and React.

Strapi exposes a plugin system where each plugin is like a small independent sub-application. It has its own business logic with dedicated models, controllers, services, middlewares or hooks. It can also have its own UI integrated in the admin panel.

I used the Roles and Permissions plugin to complete my tasks of the week. This plugin provides a way to protect our API with a full authentication process based on JWT. Each time an API request is sent, the server checks if an Authorization header is present and verifies if the user making the request has access to the resource. To do so, our JWT contains our user ID and we are able to match the group our user is in and at the end to know if the group allows access to the route.

The API response to the authentication route contains the user’s JWT in the jwt key. We will have to store this JWT in our application, it's important because you will have to use it the next requests.

We decided to store the JWT in a httpOnly cookie instead of the easy solution of storing it in localStorage which makes our application prone to XSS attacks. This means that we need to customize Strapi to set the jwt in the cookie instead of returning it in the API response. This will ensure that our front end application does not have to store sensitive data for future authenticated requests.

Strapi internally uses Koa.js , a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs. I quickly learnt basic syntax as I am already familiar with Node.js and Express .

Now every plugin in Strapi follows a fixed architecture and all installed plugins can be found in the node_modules folder with the naming convention of strapi-plugin-* .

To customize those installed plugins we can work in the /extensions directory. It contains all the plugins' customizable files. I customized the user-permissions plugin by modifying the Auth.js controller file to issue a JWT to the user and set it in a httpOnly cookie after all server side validations are done. I also changed the response by the controller to return a “status” key with “Authenticated” value instead of the token. This confirms that the user has been authenticated.

Wait! Strapi reads the token from the Authorization header in the API request so this won’t work for now. I further added a permissions.js file to the policies folder where I attach the token to the header after reading it from the cookie which was set earlier.

Policies in Strapi are functions which have the ability to execute specific logic on each request before it reaches the controller’s action. They are mostly used for securing business logic easily. Each route of the project can be associated to an array of policies.

Now to implement the logout functionality I set up a custom /logout route with a controller to set the token to null in the cookie. This destroys the user session safely in seconds.

Patience folks! Our user can forget his/her password too. I used sendgrid service to send email to users with a link which contains a URL param code which is required to reset user password.

I implemented the client side functionality including the requests to the API in a React custom hook named useAuth to finally complete the agile task.

What is coming up next?

This week I will implement the functionality to create a new request and read and display the existing feature requests along with all attributes like votes and comments in an engaging UI.

I will also try to setup providers which are currently broken due to an issue in Strapi v3.0.1 here.

Did I get stuck anywhere?

We all are bound to fall. Any great thing does not start perfect. At first I could not figure out how to manage the user state properly and tried using a reducer but the state reset itself to the initial one on page refresh. Finally I implemented the idea to read the state from localStorage without saving any sensitive information.

Strapi uses the sendmail service by default to send mails to the users but it was not working and was always returning a 400 status code. I added sendgrid service to overcome this problem.

All this hustle and bustle marked the end of my week with a mesmerizing annular solar eclipse on June 21, 2020. Stay tuned as we come up with some amazing features in the weeks ahead.

Inside look of the EOS feature request system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 15 Jun 2020 12:00:43 +0000

Hello everyone! Come join me to catch a glimpse of how things work under the hood in the EOS feature request system. You can enjoy the magic which happens behind the scenes to hold back our pleasing and engaging UI, a fit for all devices.

What did I do this week?

This week my focus was to implement a main part of the server side so that I have with me the API endpoints to interact with our applications data via the user interface.

This includes working on a famous Node.js based open source headless CMS called Strapi. The best thing I learnt about Strapi is that I can customize it and add my own logic according to the needs of my application. Strapi internally uses Koa.js, a new web framework designed by the team behind Express, which aims to be a smaller, more expressive, and more robust foundation for web applications and APIs.

I built a new content type for our feature request system. A content type is the schema of the data structure. I added suitable fields to it after some discussion about the design of our application with our mentors.

I later added another new content type on the server side for the feature requests status labels. This allows admins to create custom status labels according to their organization workflow. These have a relation with the feature requests just like a user so that we can select a status while creating a feature request.

I also came up with a custom solution for user authentication but updated it later as it did not fulfill all user cases. I customized the JWT authentication by storing it in a httpOnly cookie as discussed with my mentors earlier. This included some custom code in Koa.js to override the default behaviour of Strapi.

What is coming up next?

I will work on adding various OAuth and OAuth2 providers to enable authentication in our application. Strapi supports all major providers like Github, Facebook, Twitter and Google.

Further I will also connect the remaining login and forgot password UI to my authentication logic.

Did I get stuck anywhere?

Strapi internally uses JWT for user authentication. It returns the JWT along with the user information when the user registers or logs in. I had to customize the users-permissions plugin using the extension mechanism in Strapi .

This ensures that our front end application does not have to store sensitive data such as JWT in client side local, session or cookie storage for future authenticated requests.

I am familiar with Express and after learning basic Koa syntax I was good to go. I was then able to write some custom code in Koa to override the default behaviour of the plugin.

This closed the week and helped me learn a lot about how Strapi works internally. Stay tuned for my next blog where I will explain in detail about how I implemented a custom and secure authentication with React on the client side.

Laying out the foundations for the EOS feature request system in GSOC’20

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 08 Jun 2020 08:37:48 +0000

Hey folks! My goal is clear, the stage is set and I am ready to hit the keyboard to light up your way to the EOS feature request system which aims to provide users an accessible interface within EOS to request new features or icons.

What did I do this week?

The first task was to let users register or login to the system which means that I need to come up with the client side logic for user authentication to control if an incoming request can proceed or not.

The structure of our application is going to be a mix of public and private pages. We will have a public login page that will contain the login component to handle our authentication. We are going to be creating client only routes that are conditionally rendered using the @reach/router . The content in the private components is irrelevant for now but it’s important that the user must me logged in to access these routes.

Most of our authentication logic will be handled in a custom hook that I create which will be called useAuth and as the name implies will live inside the file useAuth.js in our hooks folder. This file will be utilizing the useReducer API to manage our user state throughout the application. I used a reducer to receive our user state object and update our state by dispatching actions.

First, I defined our DEFAULT_STATE which I am assuming is an unauthenticated user. I then created a reducer using the redux convention and switched our action.type so when I call a dispatcher function I can pass in the type of action we want to execute. I then defined various action types like REGISTER , LOGIN and LOGOUT .

For the server side implementation using Strapi, I have the user roles and permissions plugin installed at my disposal. The users and permissions role exposes a route located at http://localhost:1337/auth/local in which we can send a POST request with our users identity and password. The route will handle validation and upon successful authentication will return a jwt token to be used in further requests as well as a user object that contains information about our validated user.

I learnt that I can not user our admin username/password with this endpoint.

What is coming up next?

Devesh (my awesome GSOC partner) built an amazing responsive and engaging UI for registering users. I will connect my authentication logic with his UI to complete the feature on the client side.

On the server side I will be coming up with solutions to differentiate our database collections and routes for the EOS Design System and the EOS feature request system so that it is easy to identify them.

Did I get stuck anywhere?

Our EOS Strapi instance was running on a very old alpha version for which there was no support. My mentors did really nice work to update Strapi to the latest stable release.

Also Strapi uses JSON Web Tokens (JWT) internally for user authentication. Our team had a nice discussion on this with various ideas pouring in for the storage mechanism for the JWT which needs to be sent in an Authorization header with every request for making permission-restricted API requests.

We learnt that the JWT should not be stored in localStorage as an XSS attack can let an external attacker get access to the token.

We came up with two solutions for the storage of JWT :-

React state or memory with the only downfall that if a user refreshes the page that state is gone but we can get a new token on refresh too.
httpOnly cookie which is a special kind of cookie that’s only sent in HTTP requests to the server, and it’s never accessible (both for reading or writing) from JavaScript running in the browser.

This closed the week along with some rainfall and rainbows by our healing nature. Keep calm and stay tuned as the next batch of some amazing functionality gets loaded to our feature request system :)

First check-in to GSOC’20 @ Python Software Foundation

sharmaaditya570191@gmail.com (sharmaaditya570191) — Mon, 01 Jun 2020 05:08:19 +0000

Hello! I am Aditya Sharma, a second year Computer Science student and a Linux enthusiast who is crazy about web performance. I am really excited to work with our team of amazing mentors, developers and designers at The EOS Design System. Cheers to my journey as I share what I did before the official coding period starts.

What did I do this week?

“Live as if you were to die tomorrow. Learn as if you were to live forever.” — Mahatma Gandhi

I spent much of my time in learning in-depth the technology stack involved for my project. This mainly includes Strapi, Node.js based headless CMS for the back end and React for the front end. I also learnt about MongoDB and API design principles by implementing a ToDo API with user authentication.

My project work for the week included creating the base with router, linter and formatter configuration used at EOS for client side implementation with Create-React-App.

To save time and energy in the future I followed DRY principle (Don’t repeat yourself) and built a custom template which enables us to select a template to create our project from, while still retaining all of the features of Create React App without ejecting. This is maintained here and we published it as a NPM package here (also my first :P). My mentor Cynthia guided me really well on how to automate the package release with semantic-release and GitLab CI/CD.

What is coming up next?

As planned with my mentors I will create some models in the eos-strapi instance. Models in Strapi are a representation of the database structure and are split into two separate files. A JavaScript file that contains the model options (e.g: lifecycle hooks), and a JSON one that represents the data structure stored in the database.

I will further collaborate with Devesh(my awesome GSOC partner :) to implement authentication, authorization and identification of users on the client (React) and server side (Strapi) which internally uses JWT (JSON Web Token).

Did I get stuck anywhere?

I came across one strange problem while developing the template for Create-React-App. My implementation on running did not download the development dependencies for the project. After exploring the create-react-app repository by Facebook I found a recent commit which fixes the problem here. It will be shipped to production soon. This also helped me to learn more about how our famous zero config create-react-app does that magic internally.

This marks an outstanding start to my GSOC journey with PSF and EOS which may continue even beyond time can track. Cheers to an awesome never ending journey :)