Using OpenID - Revision history

Strattonbrazil: /* Conclusion */

2014-08-17T00:18:09Z

‎Conclusion

Strattonbrazil: /* Show Me the Code */

2014-08-17T00:17:01Z

‎Show Me the Code

Strattonbrazil: /* Show Me the Code */

2014-08-17T00:15:56Z

‎Show Me the Code

Strattonbrazil: /* Show Me the Code */

2014-08-16T23:55:00Z

‎Show Me the Code

Strattonbrazil: /* Show Me the Code */

2014-08-16T23:54:12Z

‎Show Me the Code

Strattonbrazil: /* Show Me the Code */

2014-08-16T23:53:00Z

‎Show Me the Code

Strattonbrazil: /* Show Me the Code */

2014-08-16T23:52:30Z

‎Show Me the Code

Strattonbrazil at 23:49, 16 August 2014

2014-08-16T23:49:53Z

Strattonbrazil at 23:46, 16 August 2014

2014-08-16T23:46:33Z

Strattonbrazil at 23:35, 16 August 2014

2014-08-16T23:35:25Z

← Older revision		Revision as of 00:18, 17 August 2014
Line 57:		Line 57:
	== Conclusion ==		== Conclusion ==

−	Should you always use OpenID? ~~I would say in~~ most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary. You'd still have to do things like email verification ~~to verify people's emails belong to them~~ if that's important to you. There are, of course, some cases where a username/password are required and it's fine to use them instead. Just remember that if go that route you're causing your users pain. Make sure it's worth it.	+	Should you always use OpenID? In most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary. You'd still have to do things like email verification if that's important to you. There are, of course, some cases where a username/password are required and it's fine to use them instead. Just remember that if go that route you're causing your users pain and cost you time and resources to keep them secure. Make sure it's worth it.

@@ Line 53: / Line 53: @@
 In this case we've hard-coded Google as the OpenID provider.  What's the advantage of doing this?  Well, if a user jumps to a page that requires identification, you can redirect them immediately to the Google OpenID provider and with one-click they're back on your site.  How painless is that?
-Well, what if you don't want to force Google as the OpenID provider?  Tim explains some people have added some additional logic to see which OpenID providers the user has available and chooses one of those.  Again, one click and no one got hurt.
+Well, what if you don't want to force Google as the OpenID provider?  Tim explains some people have actually added some additional logic to see which OpenID providers the user has available and chooses one of those.  Again, one click for the user and you get your juicy identification.  No one gets hurt.
 == Conclusion ==
 Should you always use OpenID?  I would say in most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary.  You'd still have to do things like email verification to verify people's emails belong to them if that's important to you.  There are, of course, some cases where a username/password are required and it's fine to use them instead.  Just remember that if go that route you're causing your users pain.  Make sure it's worth it.

@@ Line 31: / Line 31: @@
 Sounds great, right?  What does this actually involve on a developer's part?  While the protocol is relatively complex most web frameworks already have one or possibly several OpenID libraries you can use.  Take [[http://www.tornadoweb.org/en/stable/ Tornado]], an asynchronous web framework written in python as an example.  It's OpenID implementation is actually built into the framework (framework developers take note--this is awesome)!
-Here is a hello-world program for Tornado.
+Tornado provides a variety of mixins for authentication and includes one specifically for Google's (this includes the hard-coded OpenID url described earlier) called [http://www.tornadoweb.org/en/branch2.3/auth.html#google GoogleMixin].  Let's take a look at their example handler to see how it works.  I won't go into the nitty-gritty of how tornado works.
 <code>
-    import tornado.ioloop
+class MainHandler(tornado.web.RequestHandler, tornado.auth.GoogleMixin):
-    import tornado.web
+    @tornado.web.asynchronous
-    class MainHandler(tornado.web.RequestHandler):
+    def get(self):
-        def get(self):
+       if self.get_argument("openid.mode", None):
-            self.write("Hello, world")
+           self.get_authenticated_user(self.async_callback(self._on_auth))
-    application = tornado.web.Application([
+           return
-        (r"/", MainHandler),
+       self.authenticate_redirect()
-     ])
+     def _on_auth(self, user):
-    if __name__ == "__main__":
+        if not user:
-        application.listen(8888)
+            raise tornado.web.HTTPError(500, "Google auth failed")
-         tornado.ioloop.IOLoop.instance().start()
+         # Save the user with, e.g., set_secure_cookie()
 </code>
 == Conclusion ==
 Should you always use OpenID?  I would say in most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary.  You'd still have to do things like email verification to verify people's emails belong to them if that's important to you.  There are, of course, some cases where a username/password are required and it's fine to use them instead.  Just remember that if go that route you're causing your users pain.  Make sure it's worth it.

@@ Line 31: / Line 31: @@
 Sounds great, right?  What does this actually involve on a developer's part?  While the protocol is relatively complex most web frameworks already have one or possibly several OpenID libraries you can use.  Take [[http://www.tornadoweb.org/en/stable/ Tornado]], an asynchronous web framework written in python as an example.  It's OpenID implementation is actually built into the framework (framework developers take note--this is awesome)!
 <code>
      import tornado.ioloop

@@ Line 34: / Line 34: @@
      import tornado.ioloop
      import tornado.web
      class MainHandler(tornado.web.RequestHandler):
          def get(self):
              self.write("Hello, world")
      application = tornado.web.Application([
          (r"/", MainHandler),
      ])
      if __name__ == "__main__":
          application.listen(8888)

← Older revision		Revision as of 23:46, 16 August 2014
Line 24:		Line 24:

	[[File:openid_permission.png\|center]]		[[File:openid_permission.png\|center]]
		+
		+	By clicking accept, the OpenID provider redirects the user back to your site using the "return_to" field you provided the OpenID library see step 5 in the OpenID workflow diagram above). At this point you have identified the user by their email. What does this mean exactly? Well, anyone can setup their OpenID provider so this doesn't provider any email verification. So the person claiming to be "president_barack_obama@whitehouse.gov" from OpenID provider X doesn't mean he/she actually owns that email, but you can uniquely identify them as that person claiming that email from that OpenID provider.
		+
		+	== Conclusion ==
		+
		+	Should you always use OpenID? I would say in most cases OpenID is perfectly fine for many sites like forums or "toy" sites where verifying the person's actual identity isn't necessary. You'd still have to do things like email verification to verify people's emails belong to them if that's important to you. There are, of course, some cases where a username/password are required and it's fine to use them instead. Just remember that if go that route you're causing your users pain. Make sure it's worth it.

@@ Line 21: / Line 21: @@
 [[File:Openid_providers.png|center]]
-Once the user sends their provider url back to you, you then forward them to that provider (see step 1 in the OpenID workflow diagram above).
+Once the user sends their provider url back to your server, which then forwards them to that provider (see step 3 in the OpenID workflow diagram above).  This HTTP request can include specific attributes the server wants to know about the user, but in general email is always included reponse.  The OpenID provider usually provides a nice list of information being shared.  Again, if the person is already logged in to their OpenID provider, this is a one-click step!
+[[File:openid_permission.png|center]]
-−
-−
-This request can include specific attributes you'd also like to know about the user, but in general email is always included.  The OpenID provider usually provides the