RACK / SSO. and a little bit about the Bundler. Tuesday, December 1, 2009 hello hello

Transcription

1 RACK / SSO and a little bit about the Bundler hello hello

2 COREY / atmos@atmos.org i m a software developer and open source participant for a number of years this is me in hawaii last month with a much more awesome beard

3 ENGINE YARD i ve been at engineyard for 2.5 years did support for the first year, now doing internal development we do a lot of microapps

4 HANCOCK will smith was not involved in the creation of this project

5 like your john hancock not for everyone but i m hoping to keep it ongoing as a working example

6 RACK it s what everyone is using now, rails, merb, sinatra, ramaze realizing the power of rack helped me really embrace the simplicity of sinatra

7 SINATRA IS AWESOME 2009 has mainly been sinatra and datamapper for us there s still 2 merb apps we maintain, one of them is our SSO provider

8 GIT://GITHUB.COM/ATMOS/HANCOCK.GIT

9 SINGLE SIGN ON

10 TRADITIONAL OPENID user agent == browser consumer == app using openid to authenticate clients provider == openid provider the consumer talks to

11 TRADITIONAL OPENID no more specifying who you are no more consumer <-> provider identity negotiation no more choosing of profiles on the server

12 HANCOCK NEGOTIATION by cutting those out there s fewer redirects much easier to see what portions of the openid spec are used still conforms to the spec so it should be easily accessible from any language

13 # ~/p/hancock/bin/shotgun -p PORT config.ru require 'hancock' DataMapper.setup(:default, "sqlite3://#{file.dirname( FILE )}/development.rb") DataMapper.auto_migrate! Hancock::Consumer.create(:url => ' :label => 'Rails Dev', :internal => false) Hancock::Consumer.create(:url => ' :label => 'Rack Fans', :internal => false) Hancock::Consumer.create(:url => ' :label => 'Shotgun Fans', :internal => false) class Dragon < Hancock::App get '/' do redirect '/sso/login' unless session['hancock_server_user_id'] erb "<h2>hello <%= session_user.name %><!-- <%= session.inspect %>" run Dragon run Hancock::App example rackup file

14 HANCOCK-CLIENT there s a client middleware for consumers microapps are great for spikes that can expose business value with something like this we can spin up microapps quickly

15 hancock-client-rails require File.join(File.dirname( FILE ), 'boot') Rails::Initializer.run do config config.gem 'hancock', :lib => 'hancock' config.middleware.use Hancock::Client::Middleware do sso sso.sso_url = ' # all your other normal stuff middleware like this works in rails too in versions > 2.3.x you can either use the use keyword or the the generators for rails metal

16 UNDER THE HOOD it s what everyone is using now, rails, merb, sinatra, ramaze realizing the power of rack helped me really embrace the simplicity of sinatra

17

18 specific middleware use invokes initialize method it can take a block use

19 initialize arity for use first parameter is the middleware constant initializing with a block can do cool things. use in Sinatra

20 #!/usr/bin/env rackup use EY::SSO do sso sso.only_staff! use EY::ContactManager

21 use in Rails

22 config.middleware.use require File.join(File.dirname( FILE ), 'boot') Rails::Initializer.run do config config.gem 'hancock', :lib => 'hancock' config.middleware.use Hancock::Client::Middleware do sso sso.sso_url = ' # all your other normal stuff

23 script/generate metal sso # Allow the metal piece to run in isolation require(file.dirname( FILE ) + "/../../config/environment") unless defined?(rails) require 'hancock-client' class Sso < Hancock::Client::Default disable :raise_errors set :sso_url, ' works fine for inheriting from Sinatra::Default so you can write sinatra in rails if you want :)

24 map is a way to mount applications we use it for everyday kinds of things map

25 helpers do def url(path) request.script_name + path

26 #!/usr/bin/env rackup require File.dirname( FILE ) + '/lib/setup' require 'gateway/app' require 'migration/app' use Rack::Static, :urls => ["/css", "/img", "/js"], :root => "public" map "/gateway/" do use EY::SSO run Gateway::App map "/migration/" do use Rack::ShowExceptions if ENV["RACK_ENV"] == "production" use EY::SSO do sso sso.only_staff! run Migration::App map "/" do app = lambda do env [404, {"Content-Type" => "text/plain", "Content-Length" => "9"}, ["Not found"]] run app two separate apps, Migration::App and Gateway::App working fine together on subdir mappings

27 PROBLEMS

28 FRAGILE most fragile point is our integration with our CRM system, salesforce we have datamapper models but keeping things in sync proves to be crazy we use hoptoad and are diligent about resolving any exceptions we receive

29 CONFUSING usability and accessibility can easily be neglected, users get confused not being able to get every system on to something centralized leads to more confusion if you re going to go this route sp a chunk of time on the UX

30 TESTING how does SSO really behave today, will it behave that way tomorrow? providing a decent client API makes it easy to test, provide mocks instead of vice versa make it trivial to test so people actually do, cuts down on support

31 ADAPTERS MAKE IT EASY adapters allow us to pick the back we want to test at any time we don t write tests to do a full integration test, we just flip a switch to turn on a different adapter this allows us to iterate quickly on in memory mocks and run everything when the feature works

32 SECURITY sessions are cookie sessions, so they re difficult to expire on consumers there is https, the consumer whitelist allows and communicates over https :) single sign out sucks because it requires a shared domain cookie

33 YAY, COOKIE SESSIONS

34 THE BUNDLER how to deploy your new baby and ensure it ll play well with others this is how we manage lots of apps depencies in a repeatable manner think merb s bundling that actually works.

35 THE BUNDLER people can and will do crazy shit with rubygems. it s available on github under the wycats user carl lerche has done a tremous job keeping all of the insanity in order

36 gem 'rack_hoptoad', gem 'sinatra', gem 'rest-client', gem 'json' gem 'dm-core' gem 'dm-validations' gem 'do_sqlite3' '>=0.0.3' '~>0.9.4', :require_as => 'sinatra/base' :require_as => 'rest_client' only :test do gem 'rake' gem 'rspec', :require_as => %w(spec) gem 'rcov' gem 'bundler', '>=0.5.0' gem 'cucumber' gem 'webrat', '~>0.5.0' gem 'rack-test', '~>0.5.0', :require_as => 'rack/test' gem 'fakeweb', '>=1.2.5' gem 'ParseTree', '>=3.0.4', :require_as => 'parse_tree' gem 'randexp', '>=0.1.4' disable_system_gems # vim:ft=ruby DEPLOYING AN APP specify the gems you need required at runtime in a global scope all of your normal gem version hacks work as expected awkward requires can be handled easily as an array or single string

37 gem 'sinatra', '~>0.9.0', :require_as => [ ] gem 'haml', '~>2.2.0', :require_as => [ ] gem 'do_sqlite3', '~>0.9.12', :require_as => [ ] gem 'dm-validations', '~>0.9.11', :require_as => [ ] gem 'dm-timestamps', '~>0.9.11', :require_as => [ ] gem 'dm-types', '~>0.9.11', :require_as => [ ] gem 'ruby-openid', '~>2.1.7', :require_as => [ ] gem 'guid', '~>0.1.1', :require_as => [ ] gem 'rack-contrib', '~>0.9.2', :require_as => [ ] gem 'json', :require_as => [ ] only :test do gem 'rack-test', '~>0.5.0', :require_as => 'rack/test' gem 'webrat', '~>0.5.0' gem 'rspec', '~>1.2.9', :require_as => 'spec' gem 'rake' gem 'rcov' gem 'cucumber' gem 'dm-aggregates', '~>0.9.11' gem 'dm-sweatshop', '~>0.9.11' gem 'randexp' gem 'ParseTree', :require_as => 'parse_tree' gem 'bundler', '>=0.6.0' bin_path 'gbin' disable_system_gems BIN_PATH note the bin_path stuff, lots of gems distribute executables in bin, gbin stands for gem bin double check how you re bundling executables in your gems, you could easily overwrite your system rake.

38 gem 'sinatra', '~>0.9.0', :require_as => [ ] gem 'haml', '~>2.2.0', :require_as => [ ] gem 'do_sqlite3', '~>0.9.12', :require_as => [ ] gem 'dm-validations', '~>0.9.11', :require_as => [ ] gem 'dm-timestamps', '~>0.9.11', :require_as => [ ] gem 'dm-types', '~>0.9.11', :require_as => [ ] gem 'ruby-openid', '~>2.1.7', :require_as => [ ] gem 'guid', '~>0.1.1', :require_as => [ ] gem 'rack-contrib', '~>0.9.2', :require_as => [ ] gem 'json', :require_as => [ ] only :test do gem 'rack-test', '~>0.5.0', :require_as => 'rack/test' gem 'webrat', '~>0.5.0' gem 'rspec', '~>1.2.9', :require_as => 'spec' gem 'rake' gem 'rcov' gem 'cucumber' gem 'dm-aggregates', '~>0.9.11' gem 'dm-sweatshop', '~>0.9.11' gem 'randexp' gem 'ParseTree', :require_as => 'parse_tree' gem 'bundler', '>=0.6.0' bin_path 'gbin' disable_system_gems DISABLE_SYSTEM_GEMS turns out to be very useful as there won t be any system gem conflicts keeps each application nice, local and repeatably deployed.

39 Bundler.require_env(:test) require File.join(File.dirname( FILE ), '..', 'lib', 'myapp') require 'pp' DataMapper.setup(:default, 'sqlite3://:memory:') DataMapper.auto_migrate! Spec::Runner.configure do config config.include(rack::test::methods) def app MyApp.app SPEC/SPEC_HELPER.RB explicitly call Bundler.require_env(:test) to include that only block from before require your application and all is well.

40 Bundler.require_env require File.expand_path(File.join(File.dirname( FILE ), 'lib', 'my_app')) DataMapper.setup(:default, 'sqlite3://:memory:') DataMapper.auto_migrate! run MyApp.app CONFIG.RU using Bundler.require_env sets you up perfectly it runs fine under passenger other executables should be used from the bin_path directorytring

41 gem 'sinatra', '~>0.9.0', :require_as => [ ] gem 'haml', '~>2.2.0', :require_as => [ ] gem 'do_sqlite3', '~>0.9.12', :require_as => [ ] gem 'dm-validations', '~>0.9.11', :require_as => [ ] gem 'dm-timestamps', '~>0.9.11', :require_as => [ ] gem 'dm-types', '~>0.9.11', :require_as => [ ] gem 'ruby-openid', '~>2.1.7', :require_as => [ ] gem 'guid', '~>0.1.1', :require_as => [ ] gem 'rack-contrib', '~>0.9.2', :require_as => [ ] gem 'json', :require_as => [ ] only :test do gem 'rack-test', '~>0.5.0', :require_as => 'rack/test' gem 'webrat', '~>0.5.0' gem 'rspec', '~>1.2.9', :require_as => 'spec' gem 'rake' gem 'rcov' gem 'cucumber' gem 'dm-aggregates', '~>0.9.11' gem 'dm-sweatshop', '~>0.9.11' gem 'randexp' gem 'ParseTree', :require_as => 'parse_tree' gem 'bundler', '>=0.6.0' bin_path 'gbin' disable_system_gems DEPLOYING A GEM specify the gems you need required at runtime in a global scope but don t require them your application code should require them and cause bad deployments.

42 require 'rake/gempackagetask' require 'rubygems/specification' require 'date' require 'bundler' spec = Gem::Specification.new do s... manifest = Bundler::Environment.load(File.dirname( FILE ) + '/Gemfile') manifest.depencies.each do d next if d.only && d.only.include?('test') s.add_depency(d.name, d.version) YOUR RAKE FILE you can require the bundler and use your manifest file to gem depencies this way you only maintain it in one spot you could also do development depencies if you d like

43 IDENTITY lots of other realms of identity involved to really get it all right.

44 IDENTITY security + authentication + information

45 IDENTITY a slightly updated version uses oauth, we do a similar thing with the oauth provider. our next wave is to take advantage of

46 THANKS SO MUCH!

47 QUESTIONS? COMMENTS?