Book Image

Cloning Internet Applications with Ruby

By : Chang Sau Sheong
Book Image

Cloning Internet Applications with Ruby

By: Chang Sau Sheong

Overview of this book

Most users on the Internet have a few favorite Internet web applications that they use often and cannot do without. These popular applications often provide essential services that we need even while we don’t fully understand its features or how they work. Ruby empowers you to develop your own clones of such applications without much ordeal. Learning how these sites work and describing how they can be implemented enables you to move to the next step of customizing them and enabling your own version of these services.This book shows the reader how to clone some of the Internet's most popular applications in Ruby by first identifying their main features, and then showing example Ruby code to replicate this functionality.While we understand that it connects us to our friends and people we want to meet up with, what is the common feature of a social network that makes it a social network? And how do these features work? This book is the answer to all these questions. It will provide a step-by-step explanation on how the application is designed and coded, and then how it is deployed to the Heroku cloud platform. This book’s main purpose is to break up popular Internet services such as TinyURL, Twitter, Flickr, and Facebook to understand what makes it tick. Then using Ruby, the book describes how a minimal set of features for these sites can be modeled, built, and deployed on the Internet.
Table of Contents (13 chapters)

Designing the clone

For this chapter, we will be building a no-frills photo-sharing application called Photoclone, hosted at the domain

Authentication, access control, and user management

Authentication and user management follow the similar route we went through in the Tweetclone. As before we will use RPX to proxy the third party authentication providers we want to use. However, unlike in Tweetclone we're not going to provide any APIs and therefore we're not going to use any client authentication. In this case we're not going to restrict ourselves to using Google's authentication mechanism as before.

This means that for user management, the functions are split between Google and Photoclone again. The functions to change their profile, manage their passwords, and generally secure their account lies with the authentication provider. However, Photoclone requires a user entity to manage the user-to-user relationships as well as photo ownership and therefore we store...