- Programming Social Applications
- Dedication
- Preface
- 1. Social Application Container Core Concepts
- What Is a Social Application Container?
- Implementing Proprietary Versus Open Standards
- The Embedded Application: Building in a Black Box
- Embedded Application Security
- The External Application: Integrating Social Data Outside the Container
- Application Views
- Application Permission Concepts
- Client-Side Versus Server-Side Applications
- When Good Applications Go Bad
- Application Model Case Studies
- Quick-Start Tips
- 2. Mapping User Relationships with the Social Graph
- The Online Social Graph
- Applying the Real-Life Social Graph Online
- Sharing Private User Data: Opt-in Versus Opt-out
- Understanding Relationship Models
- Relationships Versus Entities
- Building Social Relevance: Exploring the Facebook Social Graph
- Defining Entity Likes and Dislikes Through the OpenLike Protocol
- Conclusion
- 3. Constructing the Foundation of a Social Application Platform
- 4. Defining Features with OpenSocial JavaScript References
- What You’ll Learn
- Including the OpenSocial Feature JavaScript Libraries
- Dynamically Setting the Height of a Gadget View
- Inserting Flash Movies in Your Gadget
- Displaying Messages to Your Users
- Saving State with User Preferences
- Setting Your Gadget Title Programmatically
- Integrating a Tabbed Gadget User Interface
- The Basic Gadget
- Creating a Tab from Markup
- Creating a Tab from JavaScript
- Getting and Setting Information About the TabSet
- Aligning tabs
- Showing and hiding tabs
- Obtaining the parent container
- Obtaining the currently selected tab
- Obtaining all tabs
- Removing a tab
- Setting the selected tab
- Swapping tab positions
- Getting and setting information about a tab
- Getting the callback of a tab
- Obtaining the content container
- Obtaining the tab position
- Obtaining the tab name
- Obtaining the tab label
- Extending Shindig with Your Own JavaScript Libraries
- Putting It All Together
- 5. Porting Applications, Profiles, and Friendships
- What You’ll Learn
- Evaluating OpenSocial Container Support
- Core Components of the OpenSocial Specification
- Cross-Container Development and Porting
- Porting Applications from Facebook to OpenSocial
- Personalizing Applications with Profile Data
- The Person Object
- Person Data Extraction Methods
- Fields Available Within the Person Object
- opensocial.Person.Field.ABOUT_ME
- opensocial.Person.Field.ACTIVITIES
- opensocial.Person.Field.ADDRESSES
- opensocial.Person.Field.AGE
- opensocial.Person.Field.BODY_TYPE
- opensocial.Person.Field.BOOKS
- opensocial.Person.Field.CARS
- opensocial.Person.Field.CHILDREN
- opensocial.Person.Field.CURRENT_LOCATION
- opensocial.Person.Field.DATE_OF_BIRTH
- opensocial.Person.Field.DRINKER
- opensocial.Person.Field.EMAILS
- opensocial.Person.Field.ETHNICITY
- opensocial.Person.Field.FASHION
- opensocial.Person.Field.FOOD
- opensocial.Person.Field.GENDER
- opensocial.Person.Field.HAPPIEST_WHEN
- opensocial.Person.Field.HAS_APP
- opensocial.Person.Field.HEROES
- opensocial.Person.Field.HUMOR
- opensocial.Person.Field.ID
- opensocial.Person.Field.INTERESTS
- opensocial.Person.Field.JOB_INTERESTS
- opensocial.Person.Field.JOBS
- opensocial.Person.Field.LANGUAGES_SPOKEN
- opensocial.Person.Field.LIVING_ARRANGEMENT
- opensocial.Person.Field.LOOKING_FOR
- opensocial.Person.Field.MOVIES
- opensocial.Person.Field.MUSIC
- opensocial.Person.Field.NAME
- opensocial.Person.Field.NETWORK_PRESENCE
- opensocial.Person.Field.NICKNAME
- opensocial.Person.Field.PETS
- opensocial.Person.Field.PHONE_NUMBERS
- opensocial.Person.Field.POLITICAL_VIEWS
- opensocial.Person.Field.PROFILE_SONG
- opensocial.Person.Field.PROFILE_URL
- opensocial.Person.Field.PROFILE_VIDEO
- opensocial.Person.Field.QUOTES
- opensocial.Person.Field.RELATIONSHIP_STATUS
- opensocial.Person.Field.RELIGION
- opensocial.Person.Field.ROMANCE
- opensocial.Person.Field.SCARED_OF
- opensocial.Person.Field.SCHOOLS
- opensocial.Person.Field.SEXUAL_ORIENTATION
- opensocial.Person.Field.SMOKER
- opensocial.Person.Field.SPORTS
- opensocial.Person.Field.STATUS
- opensocial.Person.Field.TAGS
- opensocial.Person.Field.THUMBNAIL_URL
- opensocial.Person.Field.TIME_ZONE
- opensocial.Person.Field.TURN_OFFS
- opensocial.Person.Field.TURN_ONS
- opensocial.Person.Field.TV_SHOWS
- opensocial.Person.Field.URLS
- Extending the Person Object
- Capturing the User Profile
- Using Friendships to Increase Your Audience
- Putting It All Together
- 6. OpenSocial Activities, Sharing, and Data Requests
- 7. Advanced OpenSocial and OpenSocial Next
- What You’ll Learn
- Data Pipelining
- OpenSocial Templating
- A Few More Tags: The OpenSocial Markup Language
- Localization Support with Message Bundles
- The OpenSocial REST API Libraries
- OpenSocial Next: Areas of Exploration
- OpenSocial and Distributed Web Frameworks
- Putting It All Together
- 8. Social Application Security Concepts
- What You’ll Learn
- Hosting Third-Party Code Through iframes
- A Secure Approach: The Caja Project
- Why Use Caja?
- Attack Vectors: How Caja Protects
- Setting Up Caja
- Cajoling Scripts from the Command Line
- Running Caja from a Web Application
- Running Caja with an OpenSocial Gadget
- Using JSLint to Spot JavaScript Issues Early
- Playing in the Caja Playground
- Tips for Working in a Caja Environment
- A Lighter Alternative to Caja: ADsafe
- ADsafe Versus Caja: Which One Should You Use?
- How to Implement ADsafe
- Putting It All Together
- Conclusion
- 9. Securing Social Graph Access with OAuth
- Beyond Basic Auth
- The OAuth 1.0a Standard
- OAuth 2
- OAuth 2 Workflow
- Implementation Example: Facebook
- Implementation Example: Requesting More User Information in the Facebook OAuth Process
- Implementation Example: End-User Experience
- Tips for Debugging Request Issues
- Conclusion
- 10. The Future of Social: Defining Social Entities Through Distributed Web Frameworks
- What You’ll Learn
- The Open Graph Protocol: Defining Web Pages As Social Entities
- Activity Streams: Standardizing Social Activities
- WebFinger: Expanding the Social Graph Through Email Addresses
- OExchange: Building a Social Sharing Graph
- PubSubHubbub: Content Syndication
- The Salmon Protocol: Unification of Conversation Entities
- Conclusion
- 11. Extending Your Social Graph with OpenID
- The OpenID Standard
- Do I Already Have an OpenID? How Do I Sign Up for One?
- The OpenID Authentication Flow
- OpenID Providers
- Bypassing Domain Discovery Errors in OpenID
- OpenID Extensions
- Simple Registration Extension
- Attribute Exchange Extension
- Attribute exchange types: Addresses
- Attribute exchange types: Audio and video greetings
- Attribute exchange types: Date of birth
- Attribute exchange types: Email
- Attribute exchange types: Images
- Attribute exchange types: Instant messaging
- Attribute exchange types: Name
- Attribute exchange types: Telephone
- Attribute exchange types: Websites
- Attribute exchange types: Work
- Attribute exchange types: Other personal details and preferences
- Provider Authentication Policy Extension
- Extensions Currently Under Development
- Implementation Example: OpenID
- Common Errors and Debugging Techniques
- Conclusion
- 12. Delivering User-Centric Experiences with Hybrid Auth
- The OpenID OAuth Hybrid Extension
- When Should I Use OpenID Versus Hybrid Auth?
- The OpenID OAuth Hybrid Auth Flow
- Implementation Example: OpenID, OAuth, and Yahoo!
- Application Setup: Getting Your OAuth Keys for the Hybrid Auth Process
- Implementing Hybrid Auth Using PHP
- Implementing Hybrid Auth Using Python
- Conclusion
- A. Web Development Core Concepts
- Glossary
- Index
- About the Author
- Colophon
- Copyright
Before you embark upon a particular implementation path, you should ask yourself some questions about what you need in your specific application and what’s available to you from a particular provider that you are trying to integrate.
The first question that you should ask yourself before embarking upon any approach is “What does my provider support?” Clearly, if you’re working with a service that’s an OpenID provider but does not offer OAuth, you should not be looking into a hybrid auth approach.
When working with a standard OpenID implementation, you simply need to find out two things:
Is the company that I am trying to allow a login for an OpenID provider?
What is that company’s discovery URL? (For a refresher on this topic, see the section OpenID Providers in Chapter 11.)
If the first answer is “yes,” and you have the discovery URL, you’re ready to begin integrating OpenID authentication into your site.
Now, if you’re looking into a hybrid auth approach, you’ll not only need to answer the preceding questions about OpenID, but also a number about OAuth and hybrid auth, such as:
Does the provider I’m working with support OAuth?
Does the provider I’m working with support hybrid auth to allow me to obtain a preapproved request token from OpenID, in order to exchange it for an OAuth access token?
If the answers to the preceding questions are also “yes,” then you are ready to leverage the powerful authentication and authorization functionality of a hybrid auth implementation.
If you answered “I don’t know” to any of the preceding questions, then you should check the provider’s documentation for the OpenID and OAuth specifications. Specifically, you’ll need an OpenID method for obtaining a preapproved request token at the end of the authentication process in order to implement a hybrid auth approach.
Your next question when deciding between the different standards should be, “What information about the user do I actually need?” This is an important question for a few reasons:
If you simply want to offload user authentication to another provider without having to store user credentials, or want to avoid the privacy concerns associated with storing those details, then there is absolutely no reason for you to incur the overhead and effort of implementing OAuth. If, on the other hand, you want to leverage an existing user social graph, then the OAuth implementation is your best option for accessing a great deal of data.
The provider that you are working with will most likely have a “Terms of Use” document that outlines what information about its users you are allowed to store in your own systems, and for how long. If you try to store every piece of information about a user permanently (through the OAuth process), you will more than likely be violating the provider’s terms of use.
Beyond the terms of use and authentication offload considerations, you should also be concerned about incurring an overhead that you simply may not need. We’ve touched on this already, but the point should be stressed. So, let’s take a look at this factor in a little more detail by comparing the pros and cons of each implementation.
-
No Comment