Flatiron Phase 4
My experience with phase 4 was much smoother than phase 3. A big reason for this is because of all of the headache we went through learning Rack and the abundance of material in phase 3 previously. I will say, the environment issues that had to be solved in this phase ended up being a lot more difficult than any other and it seems to be that I can thank being a PC user over Mac…haha. There were some road blocks when it came to authorization that proved to be pretty difficult and that is what wanted to talk about in this post.
I started off this phase at full speed. I was flying through the different modules and was able to keep a good pace up until authorization. One of the most difficult implementations for this project was creating a session that would authorize a user through a username and password, then save said user to a session and keep them logged in until that user logs out. Looking back at the implementation, I can see the flow and how everything links together throughout the different components to create the session upon login or signup and then saves that session in state.
These functions were responsible for capturing data upon a user logging in or signing up and then setting the user data to state to be saved in the session being created.
The above code shows the fetch that takes the data captured in the handleUserLoginAndSignup function and makes a post request to the backend in order to save it to the newly created session.
Now comes the authorization portion! Before a session is created and a user is either logged in or signed up, the following action takes place.
This action is checking to see if there is a valid session to be found or in the case of a user signing up, a session can be created successfully. If either of these return false. The authorize action will deny the creation or locating of a session and return an error. There was one key bit of code that was needed to make the authorization action work properly.
This one small line of code is responsible for ensuring that before any other action is invoked, the authorize action takes place so that no invalid sessions are being created.
I definitely had some trouble grasping authorization in the beginning. However, after practicing the implementation in the labs and researching how it worked and how others incorporated it into their applications. It all started to come together and I’ve gained a much better understanding!
