HTML and CSS Reference
In-Depth Information
How Does It Work?
In the simplest terms, Pusher provides a mechanism that lets the client “listen” for changes to the app. When
something happens, Pusher sends a notification to all the clients who are listening so that they can react
appropriately. This is the Publish Subscribe paradigm we mentioned earlier.
Chapter 3 is dedicated to the finer details, so we will skip the exercise in this section.
OAuth
Unlike the technologies discussed so far, OAuth is a protocol, not an actual programming language. It's a concept that
was drafted in 2007 to address the issue presented by websites that provided services that overlap; think about how
social networks can access your address book to look for friends or how a photo sharing site can tie into Twitter to let
your followers know when you've posted a new photo.
The problem was this: when these services first started to work together, they required that users provided a
username and password to access the service, which was potentially a huge risk. What was to stop a shady service
from using that password for its own purposes, up to and including the possibility of changing your password and
locking you out?
This was a big concern. OAuth devised a solution based on its study of a number of other attempts to solve the
problem, using what it considered to be the best parts of each.
To paraphrase an excellent analogy from the OAuth website:
13
OAuth is like giving someone the valet keys to a luxury car. A valet key will only allow the car to
drive a few miles; it doesn't allow access to the trunk; it prevents the use of any stored data in the
cars onboard computers, such as address books. OAuth is similar to a valet key for your online
services: you don't provide your password, and you're able to allow only certain privileges with the
account without exposing all of your information.
For instance, Facebook uses OAuth for user authentication on third-party services. If you're already logged in
to Facebook, you're presented with a dialog (on Facebook's domain), telling you which permissions are required
and allowing you to accept or deny the request. Privileges are compartmentalized—reading someone's timeline is
different from viewing their friends list, for example—to ensure that third-party services receive only the privileges
they
need
to function.
This keeps users safe and reduces liability for web apps. It also provides a wonderful benefit for developers: we
can allow a user to log in to our app with their Facebook, Twitter, or other credentials using a simple API.
Why Do We Need It?
We don't need it in the app that we're building, but it would be a neat feature so we've included it in Appendix A if
you want to see how it could be included. In a nutshell, we would use OAuth to eliminate the need to build a user
management system. This would also
hugely
reduce the time needed to sign up for an account without reducing the
app's access to the information it needs to function.
Let's face it: most people have more accounts than they can remember on the Internet. The difference between
someone using our app and not using our app could be something as simple as how many buttons he has to click to
get started.
Search WWH ::
Custom Search