Scramblify!

Do you truly know your music playlists? Play this Spotify inspired game to challenge your skills in word de-scrambling game personalized to you!

Comment

Inspiration

After learning about Spotify API, we were curious to see what we could create with it. However we didn't want to make a simply web player or a playlist finder. While brainstorming one of us mentioned those old scramble puzzles we would see on the internet every now and then; and at that moment it all clicked; and Scramblify was born!

What it does

The main idea of the project was for the user to be able to log in to their Spotify account, grant permissions, and display a list of public playlists from their account. Upon selecting a playlist, a scrambled list of song titles appears in which the user would then try to unscramble.

How we built it

The main highlight of our project is the back-end, mainly because it taught us a lot about OAuth.

Front-end was built using React and Axios to make requests to a custom Node server using Express, which was our back end.

The Node Server was responsible for OAuth authentication, but instead of using implicit grant flow which could be integrated directly into the front-end, Auth Code w/ PKCE flow was used instead.

The Node server was essentially used as a proxy and handled multiple sessions by storing them on Google Cloud Firestore to distinguish individual user requests. Of which, each session contained the access tokens needed to make requests to Spotify's user resources or to receive an auth code with the code_verifier and code_challenge on their authorization endpoint.

All requests were made through Node/Express server with the use of session cookies, meaning the browser never has direct access to any tokens. Instead, it makes a request to an endpoint on the Node server, which then gathers the appropriate tokens from the session and makes the corresponding request to Spotify before sending it back to the client.

In regards to our endpoints:

'/authorize': takes in our code_challenge and constructs url to return to use to grant permission

'/exchange': takes in the auth_code from our previous endpoint and code_verifier to exchange for tokens

'/resources': makes requests to the Spotify's API using tokens stored in session

Challenges we ran into

CORS issues with the Node server locally, but were eventually fixed

CORS issues after deploying the server to Google App Engine, but only on one endpoint (never figured it out), causing us to stick with the local Node server for our submission.

Preventing separate requests to Spotify's required endpoints for our OAuth flow from creating new sessions on Firestore on each request

Generating code_challenge used for PKCE

Accomplishments that we're proud of

Learning a lot more about authentication. This opens up so many more doors for projects compared to traditional public APIs where you would just need a key. Now we can use accounts for services that have things that actually belong to us, like our own playlists on Spotify for example.

What we learned

Learning how to use Node and Express was new to us. Also understanding how OAuth works and the different kinds of OAuth flows. Security was also a new thing that we tried learning. This involved thinking about where tokens would be exposed, how to store them, and where to store them.

Also we learned that air beds are a must for 24 hour events.

What's next for Scramblify!

We did not get to finish the different types of scrambling that we wanted, which is indicated by the navigation bar on the side. We could also not style as much as we wanted, so we hope to finish this in the future.

Hopefully we are able to fix the issue with the Node application having some CORS trouble on Google App Engine in the future. This would mean that we would all be able to test the endpoints at the same time. Since Google Firestore was linked to a single person's account, the credentials for the database would only apply to that person's signed in account on their machine.

Built With

Share this project:

Updates